Re: Fastest way to read OLDEST GDG entry

[Walt Farrell]

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 that it impacts your processing unacceptably?

CSI is a better approach than reading the output of LISTC, in my opinion, as 
the LISTC output is not a programming interface.

But whatever you do, you may have a TOCTTOU (time of check to time of use) 
issue. By the time you figure out what the oldest GDG member is, and go to read 
it, it may no longer exist. So don't forget to put in some error checking for 
that case.

-- 
Walt

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Fastest way to read OLDEST GDG entry

[Greg Shirey]

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 Lizette Koehler
Sent: Tuesday, November 17, 2015 4:06 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: 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 GDGORDER on the JCL for z/OS V2.1 and it works great on the Base.  But 
using //DDSTMT DD DISP=SHR,DSN=GDDG(0),GDGORDER=FIFO does not seem to work.

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 going to see if the LISTC could be faster than CSI.  

The process should be native to z/OS and not a vendor product.  Or 
shareware/freeware is okay.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Fastest way to read OLDEST GDG entry

[Elardus Engelbrecht]

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 version of GDDG?)

I tried this before posting on a GDG of 5 with JCL DD MY.GDG(-6). Only got a 
JCL error as documented...

>But CSI is slow sometimes and better other times.

Limiting the scope of CSI searches could speed things up, unless you want to do 
a big search.

>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

>Or is there another way to handle this situation?  I was going to see if the 
>LISTC could be faster than CSI.

LISTC could be faster. Just use the First ASSOCIATIONS in GDG BASE output.

But then wraparound of version numbers could be a problem.

Groete / Greetings
Elardus Engelbrecht

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: OT - another Legacy operating system

[John McKown]

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" (FSVO "reasonable") to me. Lets face it​. Doing
"unnecessary" upgrades (I.e. upgrades which are not critical) costs money.
That means spending money. For public sector, the money comes from tax
payers (or fees). Which is politically "irresponsible" because there's
always some "investigative reporter" looking for "government waste". For
the private sector, it's even easier: spending "unnecessary" money means
not meeting budgets. Which decreases management's bonuses. Very evil.

Yes, I'm very cynical any more.

-- 

Schrodinger's backup: The condition of any backup is unknown until a
restore is attempted.

Yoda of Borg, we are. Futile, resistance is, yes. Assimilated, you will be.

He's about as useful as a wax frying pan.

10 to the 12th power microphones = 1 Megaphone

Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Fastest way to read OLDEST GDG entry

[Bill Ashton]

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 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.
> >
> > 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 GDGORDER on the JCL for z/OS V2.1 and it works great on the
> Base.  But
> > using //DDSTMT DD DISP=SHR,DSN=GDDG(0),GDGORDER=FIFO does not seem to
> work.
> >
> > 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 going to see if the LISTC could be faster than CSI.
> >
> > The process should be native to z/OS and not a vendor product.  Or
> > shareware/freeware is okay.
> >
> > Thanks
> >
> > Lizette Koehler
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
>
> --
> Mike A Schwab, Springfield IL USA
> Where do Forest Rangers go to get away from it all?
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
Thank you and best regards,
*Billy Ashton*

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: OT - another Legacy operating system

[Jon Butler]

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.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Fastest way to read OLDEST GDG entry

[Tom Marchant]

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

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: OT - another Legacy operating system

[Paul Gilmartin]

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 I was the only user of Win3.1 while other migrated to Win95 
> or Win98 (and some WinNT4). My computer was the only one not-vulnerable for 
> any attack my network guys could imagine and test. They were able to kill any 
> machine on the network except mine.
> Last, but not least: isolated environment provide physical security.
>  
Related:

http://www.nytimes.com/2015/11/18/technology/microsoft-once-infested-with-security-flaws-does-an-about-face.html

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

AW: Re: Fastest way to read OLDEST GDG entry

[Peter Hunkeler]

> 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



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Help with mount?

[Hansen, Dave L - Eagan, MN]

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 do we set "mount authority"?  I use IBMUSER (uid 0).


  Thank you,  Dave

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Fastest way to read OLDEST GDG entry

[Mike Schwab]

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 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
>
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Fastest way to read OLDEST GDG entry

[Bill Ashton]

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 <
elardus.engelbre...@sita.co.za> wrote:

> 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 version of GDDG?)
>
> I tried this before posting on a GDG of 5 with JCL DD MY.GDG(-6). Only got
> a JCL error as documented...
>
> >But CSI is slow sometimes and better other times.
>
> Limiting the scope of CSI searches could speed things up, unless you want
> to do a big search.
>
> >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
>
> >Or is there another way to handle this situation?  I was going to see if
> the LISTC could be faster than CSI.
>
> LISTC could be faster. Just use the First ASSOCIATIONS in GDG BASE output.
>
> But then wraparound of version numbers could be a problem.
>
> Groete / Greetings
> Elardus Engelbrecht
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
Thank you and best regards,
*Billy Ashton*

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Fastest way to read OLDEST GDG entry

[Mike Schwab]

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.
>
> 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 GDGORDER on the JCL for z/OS V2.1 and it works great on the Base.  But
> using //DDSTMT DD DISP=SHR,DSN=GDDG(0),GDGORDER=FIFO does not seem to work.
>
> 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 going to see if the LISTC could be faster than CSI.
>
> The process should be native to z/OS and not a vendor product.  Or
> shareware/freeware is okay.
>
> Thanks
>
> Lizette Koehler
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

AW: Re: Fastest way to read OLDEST GDG entry

[Peter Hunkeler]

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 seem to remember 
it an OPEN exit.

If reading all GDSs via base entry behaves similarly, you could just terminate 
processing upon first invocation of that code. Using GDGORDER=FIFO, your 
program would do what you want. The code would need to find the actual dsn of 
the (first) data set right after open, so it can delete it.


I can dig out some code if you like to further follow this vague idea.

--
Peter Hunkeler



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: OT - another Legacy operating system

[R.S.]

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 software quit if it had been
running for 23 years.


​I hadn't noticed that, not speaking French. It would _amaze_ me to have a
PC running for 23 years.​ But, then, I have a PC which has been running
since about 2003 here at home.
Well, I had "bridge computer" in my home. It was PC 286 1MB RAM, with 
5,25" HDD (40MB) and DOS, kept for Bridge computer game and some other 
ancient games.
It was placed on the side (against HDD rules) and fell several times. 
Finally power supply switch (yes! ON/Off switch!) broke and I removed 
it. It was approx. 17 years old.


Another example: our very first computer in the company (actually, this 
sub-company) is still working as a display of some PCOMM screens. It is 
approx. 19 years old. However it's "modern" Pentium MMX with 16MB of RAM 
and huge 2-3 GB HDD.



--
Radoslaw Skorupka
Lodz, Poland






--
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.pl
Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru 
Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. 
Według stanu na dzień 01.01.2015 r. kapitał zakładowy mBanku S.A. (w całości 
wpłacony) wynosi 168.840.228 złotych.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: OT - another Legacy operating system

[Vernooij, CP (ITOPT1) - KLM]

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
Subject: 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
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Fastest way to read OLDEST GDG entry

[Sri h Kolusu]

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 
  INCLUDE COND=(4,7,CH,EQ,C'NONVSAM') 
  INREC BUILD=(C'//SYSUT1 DD DISP=SHR,DSN=',17,44,80:X) 
//* 

Further if you have any questions please let me know

There are couple of other GDG related tricks listed in there which might 
be of use


Thanks,
Kolusu
DFSORT Development
IBM Corporation



From:   Lizette Koehler 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   11/17/2015 03:06 AM
Subject:Fastest way to read OLDEST GDG entry
Sent by:IBM Mainframe Discussion List 



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 GDGORDER on the JCL for z/OS V2.1 and it works great on the Base. 
But
using //DDSTMT DD DISP=SHR,DSN=GDDG(0),GDGORDER=FIFO does not seem to 
work.

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 going to see if the LISTC could be faster than CSI. 

The process should be native to z/OS and not a vendor product.  Or
shareware/freeware is okay.

Thanks

Lizette Koehler

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN





--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: OT - another Legacy operating system

[Charles Mills]

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 6:03 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: 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 years.
>

​I hadn't noticed that, not speaking French. It would _amaze_ me to have a PC 
running for 23 years.​ But, then, I have a PC which has been running since 
about 2003 here at home.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Fastest way to read OLDEST GDG entry

[Shmuel Metz (Seymour J.)]

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
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: OT - another Legacy operating system

[Shmuel Metz (Seymour J.)]

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
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

[Shmuel Metz (Seymour J.)]

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 the next one.

That might work if you have the unlike attributes bit set, but since
you are only going to process one data set, why not use RDJFCB to get
the name?
 
-- 
 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 Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: OT - another Legacy operating system

[R.S.]

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 migrated to 
Win95 or Win98 (and some WinNT4). My computer was the only one 
not-vulnerable for any attack my network guys could imagine and test. 
They were able to kill any machine on the network except mine.

Last, but not least: isolated environment provide physical security.

--
Radoslaw Skorupka
Lodz, Poland






--
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.pl
Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru 
Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. 
Według stanu na dzień 01.01.2015 r. kapitał zakładowy mBanku S.A. (w całości 
wpłacony) wynosi 168.840.228 złotych.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Fastest way to read OLDEST GDG entry

[Tom Marchant]

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 to process generation data sets in the order they were created.

>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.

The limit can be 999, but it is not automatically changed.

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Fastest way to read OLDEST GDG entry

[Burrell, C. Todd (CDC/OCOO/OCIO/ITSO) (CTR)]

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 Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Tuesday, November 17, 2015 9:07 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: 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 then read and processed to the current version.

I believe date/time read of a seq file has always been a challenge on the 
mainframe as the naming convention does not allow for a more granular read of 
many files into input.

So I have the following conditions

File1 created on date and time
File2 created on date and time+15 mins
File3 created on date and time+60 mins

Then I need to read File1 first, process it, delete it Next file2, process it 
and delete it Next File3, process it and delete it

All the time new files are coming in.

If I delete the GDG base I may delete data that is not processed.

The file cannot be mod'd due to the face it is a TSO XMIT'd file.  I need to 
RECEIVE the GDG (oldest version) process it and then delete what I have just 
processed.

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


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Greg Shirey
> Sent: Tuesday, November 17, 2015 6:50 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: 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 Lizette Koehler
> Sent: Tuesday, November 17, 2015 4:06 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: 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 GDGORDER on the JCL for z/OS V2.1 and it works great on the 
> Base.  But
using
> //DDSTMT DD DISP=SHR,DSN=GDDG(0),GDGORDER=FIFO does not seem to work.
> 
> 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 going
> to see if the LISTC could be faster than CSI.
> 
> The process should be native to z/OS and not a vendor product.  Or 
> shareware/freeware is okay.

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: OT - another Legacy operating system

[Vernooij, CP (ITOPT1) - KLM]

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. You can't blame the computer for not being configured 
redundantly. We all know who is to blame for that.

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jon Butler
Sent: 17 November, 2015 14:51
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: 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.   

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Fastest way to read OLDEST GDG entry

[John McKown]

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
in" are at the limit.​

It might be interesting to understand _exactly_ what the OP is trying to
accomplish by reading in the "oldest" GDG and exactly how said generations
are being created. I don't know why the OP says that IGGCSI00 is "slow". I
may, when I feel better, look at writing a C program which uses IGGCSI00 to
do "something or other" like this.

Another thought, from way out in left field, is to create a SUBSYS=, say
called LGDG, which would do exactly what the OP wants. Something like:

//SYSUT1 DD SUBSYS=(LGDG,'gdg.base.name')

which looks up "gdg.base.name" and then allocates the generation (SVC 99)
with the lowest generation number. Of course, this does not allow the
deletion of said GDG. But that could possibly be done with other options.


>
> Regards,
> Greg Shirey
> Ben E. Keith Company
>

-- 

Schrodinger's backup: The condition of any backup is unknown until a
restore is attempted.

Yoda of Borg, we are. Futile, resistance is, yes. Assimilated, you will be.

He's about as useful as a wax frying pan.

10 to the 12th power microphones = 1 Megaphone

Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Fastest way to read OLDEST GDG entry

[Lizette Koehler]

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 Ashton
> Sent: Tuesday, November 17, 2015 5:21 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: 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 <
> elardus.engelbre...@sita.co.za> wrote:
> 
> > 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 version of GDDG?)
> >
> > I tried this before posting on a GDG of 5 with JCL DD MY.GDG(-6). Only
> > got a JCL error as documented...
> >
> > >But CSI is slow sometimes and better other times.
> >
> > Limiting the scope of CSI searches could speed things up, unless you
> > want to do a big search.
> >
> > >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
> >
> > >Or is there another way to handle this situation?  I was going to see
> > >if
> > the LISTC could be faster than CSI.
> >
> > LISTC could be faster. Just use the First ASSOCIATIONS in GDG BASE output.
> >
> > But then wraparound of version numbers could be a problem.
> >
> > Groete / Greetings
> > Elardus Engelbrecht
> >

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Fastest way to read OLDEST GDG entry

[Jousma, David]

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?

_
Dave Jousma
Assistant Vice President, Mainframe Engineering
david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H
p 616.653.8429
f 616.653.2717

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Tuesday, November 17, 2015 8:55 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: 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 Ashton
> Sent: Tuesday, November 17, 2015 5:21 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: 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 < 
> elardus.engelbre...@sita.co.za> wrote:
> 
> > 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 version of GDDG?)
> >
> > I tried this before posting on a GDG of 5 with JCL DD MY.GDG(-6). 
> > Only got a JCL error as documented...
> >
> > >But CSI is slow sometimes and better other times.
> >
> > Limiting the scope of CSI searches could speed things up, unless you 
> > want to do a big search.
> >
> > >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
> >
> > >Or is there another way to handle this situation?  I was going to 
> > >see if
> > the LISTC could be faster than CSI.
> >
> > LISTC could be faster. Just use the First ASSOCIATIONS in GDG BASE output.
> >
> > But then wraparound of version numbers could be a problem.
> >
> > Groete / Greetings
> > Elardus Engelbrecht
> >

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: OT - another Legacy operating system

[John McKown]

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 years.
>

​I hadn't noticed that, not speaking French. It would _amaze_ me to have a
PC running for 23 years.​ But, then, I have a PC which has been running
since about 2003 here at home.

$uname -a
Linux mckown4.johnmckown.net 2.4.20-8 #1 Thu Mar 13 17:54:28 EST 2003 i686
i686 i386 GNU/Linux


-- 

Schrodinger's backup: The condition of any backup is unknown until a
restore is attempted.

Yoda of Borg, we are. Futile, resistance is, yes. Assimilated, you will be.

He's about as useful as a wax frying pan.

10 to the 12th power microphones = 1 Megaphone

Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Fastest way to read OLDEST GDG entry

[Lizette Koehler]

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 then read and processed to the current version.

I believe date/time read of a seq file has always been a challenge on the
mainframe as the naming convention does not allow for a more granular read of
many files into input.

So I have the following conditions

File1 created on date and time
File2 created on date and time+15 mins
File3 created on date and time+60 mins

Then I need to read File1 first, process it, delete it
Next file2, process it and delete it
Next File3, process it and delete it

All the time new files are coming in.

If I delete the GDG base I may delete data that is not processed.

The file cannot be mod'd due to the face it is a TSO XMIT'd file.  I need to
RECEIVE the GDG (oldest version) process it and then delete what I have just
processed.

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


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Greg Shirey
> Sent: Tuesday, November 17, 2015 6:50 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: 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 Lizette Koehler
> Sent: Tuesday, November 17, 2015 4:06 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: 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 GDGORDER on the JCL for z/OS V2.1 and it works great on the Base.  But
using
> //DDSTMT DD DISP=SHR,DSN=GDDG(0),GDGORDER=FIFO does not seem to work.
> 
> 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 going
> to see if the LISTC could be faster than CSI.
> 
> The process should be native to z/OS and not a vendor product.  Or
> shareware/freeware is okay.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Fastest way to read OLDEST GDG entry

[Richard Pinion]

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 entry
Date: Tue, 17 Nov 2015 14:17:04 +

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 Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Tuesday, November 17, 2015 9:07 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: 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 then read and processed to the current version.

I believe date/time read of a seq file has always been a challenge on the 
mainframe as the naming convention does not allow for a more granular read of 
many files into input.

So I have the following conditions

File1 created on date and time
File2 created on date and time+15 mins
File3 created on date and time+60 mins

Then I need to read File1 first, process it, delete it Next file2, process it 
and delete it Next File3, process it and delete it

All the time new files are coming in.

If I delete the GDG base I may delete data that is not processed.

The file cannot be mod'd due to the face it is a TSO XMIT'd file.  I need to 
RECEIVE the GDG (oldest version) process it and then delete what I have just 
processed.

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


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Greg Shirey
> Sent: Tuesday, November 17, 2015 6:50 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: 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 Lizette Koehler
> Sent: Tuesday, November 17, 2015 4:06 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: 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 GDGORDER on the JCL for z/OS V2.1 and it works great on the 
> Base.  But
using
> //DDSTMT DD DISP=SHR,DSN=GDDG(0),GDGORDER=FIFO does not seem to work.
> 
> 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 going
> to see if the LISTC could be faster than CSI.
> 
> The process should be native to z/OS and not a vendor product.  Or 
> shareware/freeware is okay.

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN




_
Netscape.  Just the Net You Need.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Fastest way to read OLDEST GDG entry

[Paul Gilmartin]

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?

But how many specific catalog searches break even with a single generic search?

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Fastest way to read OLDEST GDG entry

[Paul Gilmartin]

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 it compares to Classic 
catalog
search.  Shadow your G00*V00 names with empty files in a UNIX directory and
use that as an index.  Bizarre?  Well, before VSAM programmers used empty PDS
members as similar placeholders.

Directory search in z/OS may be faster than in competing UNIXen because z/OS
indexes its directories.  Don't know about the others.

And readdir() will return the smallest (oldest?) G00*V00 first, so you could
bail out there.

VSAM index?  PDSE with empty members used as index?  Deleting the lowest
named PDS member is the worst performance case; don't know about PDSE.

How many is "lots"?

What makes "V00" ever Vnn, where N<>0?

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Fastest way to read OLDEST GDG entry

[Lucas Rosalen]

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 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?
>
> But how many specific catalog searches break even with a single generic
> search?
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Help with mount?

[Steve Beaver]

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
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: 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 do we set "mount authority"?  I use IBMUSER (uid 0).


  Thank you,  Dave

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email
to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Fastest way to read OLDEST GDG entry

[John McKown]

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 DSN FOUND */
"RECEIVE INDATASET('"DSN"')"

​I recall that doing a RECEIVE in REXX is "iffy". Perhaps another person
remembers how to do this?​


-- 

Schrodinger's backup: The condition of any backup is unknown until a
restore is attempted.

Yoda of Borg, we are. Futile, resistance is, yes. Assimilated, you will be.

He's about as useful as a wax frying pan.

10 to the 12th power microphones = 1 Megaphone

Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Fastest way to read OLDEST GDG entry

[Burrell, C. Todd (CDC/OCOO/OCIO/ITSO) (CTR)]

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 Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: Tuesday, November 17, 2015 1:45 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: 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 DSN FOUND */ "RECEIVE INDATASET('"DSN"')"

​I recall that doing a RECEIVE in REXX is "iffy". Perhaps another person 
remembers how to do this?​


-- 

Schrodinger's backup: The condition of any backup is unknown until a restore is 
attempted.

Yoda of Borg, we are. Futile, resistance is, yes. Assimilated, you will be.

He's about as useful as a wax frying pan.

10 to the 12th power microphones = 1 Megaphone

Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Fastest way to read OLDEST GDG entry

[J O Skip Robinson]

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 for RECEIVE may 
depend on the data set XMITted. One solution might be to issue RECEIVE, trap 
the output that contains the data set name, and END without actually receiving 
the data set. Then construct a prompt response based the known data set name, 
QUEUE the appropriate response, and issue RECEIVE again. Might be undoable if 
more than one data set is waiting for RECEIVE.

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: Tuesday, November 17, 2015 10:45 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):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 DSN FOUND */ "RECEIVE INDATASET('"DSN"')"

​I recall that doing a RECEIVE in REXX is "iffy". Perhaps another person 
remembers how to do this?​


-- 

Schrodinger's backup: The condition of any backup is unknown until a restore is 
attempted.

Yoda of Borg, we are. Futile, resistance is, yes. Assimilated, you will be.

He's about as useful as a wax frying pan.

10 to the 12th power microphones = 1 Megaphone

Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Moving a Sysplex

[Mark Jacobs - Listserv]

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 General David Morrison

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Fastest way to read OLDEST GDG entry

[Paul Gilmartin]

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 must be read in correct order for time/date processing
>
>I tried GDGORDER on the JCL for z/OS V2.1 and it works great on the Base.  But
>using //DDSTMT DD DISP=SHR,DSN=GDDG(0),GDGORDER=FIFO does not seem to work.
>
>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 going to see if the LISTC could be faster than CSI.
>
>The process should be native to z/OS and not a vendor product.  Or
>shareware/freeware is okay.
>
For CSI, I find a SHARE presentation about a year old:
https://share.confex.com/share/122/webprogram/Session14633.html

Which mentions SYS1.SAMPLIB(IGGCSIRX).  Trying that, it returns GDG bases
but not members.  Or I don't know enough about catalogs to supply the
correct filters.

It returns 58 entries in 0.4 seconds elapsed.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: (External):Re: Moving a Sysplex

[Jerry Whitteridge]

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 [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of J O Skip Robinson
Sent: Tuesday, November 17, 2015 3:16 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: 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 allow any actual 
production work, which would have updated data in a (possibly) throw-away 
location. There was no going back.

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jerry Whitteridge
Sent: Tuesday, November 17, 2015 2:56 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):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 and verify.

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 [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mark Jacobs - Listserv
Sent: Tuesday, November 17, 2015 2:51 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: 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 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 production DASD volumes to GDPS-mirrored 
> volumes. I just don't see how you could do that seamlessly. We 
> performed a multi-sysplex move a couple of years back using 
> essentially GDPS DR procedures, but we took a full outage to 
> accomplish it.
>
> .
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 626-302-7535 Office
> 323-715-0595 Mobile
> jo.skip.robin...@sce.com
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Mark Jacobs - Listserv
> Sent: Tuesday, November 17, 2015 11:02 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):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 General David Morrison
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
> Please be alert for any emails that may ask you for login information 
> or directs you to login via a link. If you believe this message is a 
> phish or aren't sure whether this message is trustworthy, please send 
> the original message as an attachment to 'phish...@timeinc.com'.
>

-- 

Mark Jacobs
Time Customer Service
Technology and Product Engineering

The standard you walk past is the standard you accept.
Lt. Gen. David Morrison

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

"Email Firewall" made the following annotations.
--

Warning: 
All e-mail sent to this address will be received by the corporate e-mail 
system, and is subject to archival and review by someone other than the 
recipient.  This e-mail may contain proprietary information and is intended 
only for the use of the intended recipient(s).  If the reader of this message 
is not the intended 

Re: Moving a Sysplex

[Jerry Whitteridge]

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 and verify.

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 [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mark Jacobs - Listserv
Sent: Tuesday, November 17, 2015 2:51 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: 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 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 production DASD volumes to GDPS-mirrored volumes. I 
> just don't see how you could do that seamlessly. We performed a 
> multi-sysplex move a couple of years back using essentially GDPS DR 
> procedures, but we took a full outage to accomplish it.
>
> .
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 626-302-7535 Office
> 323-715-0595 Mobile
> jo.skip.robin...@sce.com
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Mark Jacobs - Listserv
> Sent: Tuesday, November 17, 2015 11:02 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):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 General David Morrison
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
> Please be alert for any emails that may ask you for login information 
> or directs you to login via a link. If you believe this message is a 
> phish or aren't sure whether this message is trustworthy, please send 
> the original message as an attachment to 'phish...@timeinc.com'.
>

-- 

Mark Jacobs
Time Customer Service
Technology and Product Engineering

The standard you walk past is the standard you accept.
Lt. Gen. David Morrison


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

"Email Firewall" made the following annotations.
--

Warning: 
All e-mail sent to this address will be received by the corporate e-mail 
system, and is subject to archival and review by someone other than the 
recipient.  This e-mail may contain proprietary information and is intended 
only for the use of the intended recipient(s).  If the reader of this message 
is not the intended recipient(s), you are notified that you have received this 
message in error and that any review, dissemination, distribution or copying of 
this message is strictly prohibited.  If you have received this message in 
error, please notify the sender immediately.. 
 
==

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: (External):Re: Moving a Sysplex

[J O Skip Robinson]

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 allow any actual 
production work, which would have updated data in a (possibly) throw-away 
location. There was no going back.

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jerry Whitteridge
Sent: Tuesday, November 17, 2015 2:56 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):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 and verify.

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 [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mark Jacobs - Listserv
Sent: Tuesday, November 17, 2015 2:51 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: 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 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 production DASD volumes to GDPS-mirrored 
> volumes. I just don't see how you could do that seamlessly. We 
> performed a multi-sysplex move a couple of years back using 
> essentially GDPS DR procedures, but we took a full outage to 
> accomplish it.
>
> .
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 626-302-7535 Office
> 323-715-0595 Mobile
> jo.skip.robin...@sce.com
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Mark Jacobs - Listserv
> Sent: Tuesday, November 17, 2015 11:02 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):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 General David Morrison
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
> Please be alert for any emails that may ask you for login information 
> or directs you to login via a link. If you believe this message is a 
> phish or aren't sure whether this message is trustworthy, please send 
> the original message as an attachment to 'phish...@timeinc.com'.
>

-- 

Mark Jacobs
Time Customer Service
Technology and Product Engineering

The standard you walk past is the standard you accept.
Lt. Gen. David Morrison

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: OT - another Legacy operating system

[Ed Gould]

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

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Fastest way to read OLDEST GDG entry

[Paul Gilmartin]

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 going to see if the LISTC could be faster than CSI.
>> 
Naively, I'd expect that LISTCAT use CSI, or something very similar.

>For CSI, I find a SHARE presentation about a year old:
>https://share.confex.com/share/122/webprogram/Session14633.html
>
>Which mentions SYS1.SAMPLIB(IGGCSIRX).  Trying that, it returns GDG bases
>but not members.  Or I don't know enough about catalogs to supply the
>correct filters.
>
Looking further at:
z/OS 2.1.0>z/OS DFSMS>z/OS DFSMS Managing Catalogs>Catalog Search Interface 
User's Guide>Selection Criteria Fields
z/OS DFSMS Managing Catalogs
SC23-6853-00 
... the field descriptions seem to be garbled.  I see:

132(84) Character   1   CSIDTYPSEntry types to be 
returned. All types = blanks

... one character.  But in the detail below, I see:
CSIDTYPS, Entry Types
...
The valid types can be mixed and in any order. Blanks cannot separate the 
types. For instance,
“ABH” might be specified to get only the non-VSAM, generation data group 
and generation
data set entries.

... multiple characters.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Moving a Sysplex

[Mark Jacobs - Listserv]

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 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 production DASD volumes to GDPS-mirrored volumes. I 
just don't see how you could do that seamlessly. We performed a 
multi-sysplex move a couple of years back using essentially GDPS DR 
procedures, but we took a full outage to accomplish it.


.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
On Behalf Of Mark Jacobs - Listserv

Sent: Tuesday, November 17, 2015 11:02 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):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 General David Morrison

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Please be alert for any emails that may ask you for login information 
or directs you to login via a link. If you believe this message is a 
phish or aren't sure whether this message is trustworthy, please send 
the original message as an attachment to 'phish...@timeinc.com'.




--

Mark Jacobs
Time Customer Service
Technology and Product Engineering

The standard you walk past is the standard you accept.
Lt. Gen. David Morrison


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Moving a Sysplex

[J O Skip Robinson]

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 production DASD 
volumes to GDPS-mirrored volumes. I just don't see how you could do that 
seamlessly. We performed a multi-sysplex move a couple of years back using 
essentially GDPS DR procedures, but we took a full outage to accomplish it. 

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mark Jacobs - Listserv
Sent: Tuesday, November 17, 2015 11:02 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):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 General David Morrison

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

AW: Re: Help with mount?

[Peter Hunkeler]

> 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 doing the mount/unmount is running with an MVS userid that has 
been given READ or UPDATE permission to profile SUPERUSER.FILESYS.MOUNT in the 
UNIXPRIV class (RACF). READ allows mounts with NOSETUID attribute, only. UPDATE 
allows SETUID or NOSETUID.


See z/OS UNIX System Serives PLanning Guide for details on the various UNIXPRIV 
class profiles.


--
Peter Hunkeler

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Fastest way to read OLDEST GDG entry

[Mike Schwab]

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 data.set.name.G0123V01
DISP=(NEW,CATLG).
I had to fix some bad records with IEBGENER control cards.

-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

[John Dawes]

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 November, 2015, 5:13 AM
 
 John,
 
 Did you find a solution? 
 Just
 interested.
 
 Kees.
 
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
 On Behalf Of John Dawes
 Sent: 10 November,
 2015 16:19
 To: IBM-MAIN@LISTSERV.UA.EDU
 Subject: JCL QUESTION :IGD17045I SPACE NOT
 SPECIFIED FOR ALLOCATION OF DATA SET
 
 G'Day 
 
 I
 have a problem with allocating a dsn to tape.  This problem
 started when we transferred from Oracle VSM to IBM VTS. 
 
 
 The error message is as
 follows:
 
 IEF344I MVRXL#JP
 TSO CUMUL OUTPUT01 - ALLOCATION FAILED DUE TO DATA FACILITY
 SYSTEM ERROR
 IGD17045I SPACE NOT SPECIFIED
 FOR ALLOCATION OF DATA SET                   
    
 SYSCICS.CICS.CICSVP.G0005V00   
    
 
 This job has
 been running without any problem when it was allocated under
 VSM however with the switch to VTS the abends have occurred
 due to the AFF parm.
 
 Below
 is the jcl:
 
 //ACUMUL  EXEC
 IKJEFT01,                       
    
 //         
    PARM=('CICSAPP')             
     
 //*                     
                          
 //STEP1  DD
 DISP=(SHR,PASS),DSN=&     
    
 //CICSLIST DD
 DSN=&,DISP=(SHR,DELETE)      
 //SYSTSPRT DD SYSOUT=*               
             
 //SYSPRINT DD SYSOUT=* 
                           
 //SYSTSIN  DD DUMMY                 
              
 //*       
                                    
    
 //A3490    DD 
 UNIT=(3490,,DEFER)                 
 //OUTPUT01 DD DSN=SYSCICS.CICS.CICSVP(+1), 
 //            DISP=(NEW,CATLG,DELETE), 
           
 //           
 DCB=MODDSCB,                        
 //            RECFM=VB,LRECL=32756,   
            
 //         
   UNIT=AFF=A3490,LABEL=EXPDT=99000    
 
 As a temporary workaround I
 have removed the AFF parm (UNIT=3490,LABEL=EXPDT=99000)
 however because of JCL changes that would need to be done
 which the user would like to avoid can something else be
 done?
 
 Please note that NO
 SMS changes have been done since 2013 even though the error
 message points out to a SMS problem.
  
 Thanks. 
 
 
 //*                 
                              
 
 --
 For IBM-MAIN subscribe / signoff / archive
 access instructions,
 send email to lists...@listserv.ua.edu
 with the message: INFO IBM-MAIN
 
 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...@listserv.ua.edu
 with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Fastest way to read OLDEST GDG entry

[Shane Ginnane]

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 GDG?  Or is there another way to handle this situation? 
>>> I
>>>was going to see if the LISTC could be faster than CSI.
>>> 
>Naively, I'd expect that LISTCAT use CSI, or something very similar.

Been a while, but the samples I looked at were just that - and did need some 
cleaning up. Mark Z will have a bunch of good examples for sure.
LISTCAT using generics was awful - I seem to remember some fixes for that a 
while back - but CSI when properly constructed was awesome. Done in assembler 
more so, as expected.
It looks like it finds *everything* - including the connector records for cats 
that have been disconnected. I found myself running through mastercats I 
shouldn't have been even able to see. Like I said, if you are careful, CSI is 
awesome.

Shane ...

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Fastest way to read OLDEST GDG entry

[Clark Morris]

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.
>
>Keep an external index?
>
>z/OS UNIX directory search is fast; I don't know how it compares to Classic 
>catalog
>search.  Shadow your G00*V00 names with empty files in a UNIX directory and
>use that as an index.  Bizarre?  Well, before VSAM programmers used empty PDS
>members as similar placeholders.
>
>Directory search in z/OS may be faster than in competing UNIXen because z/OS
>indexes its directories.  Don't know about the others.
>
>And readdir() will return the smallest (oldest?) G00*V00 first, so you could
>bail out there.
>
>VSAM index?  PDSE with empty members used as index?  Deleting the lowest
>named PDS member is the worst performance case; don't know about PDSE.
>
>How many is "lots"?
>
>What makes "V00" ever Vnn, where N<>0?

Running a program that copies the file doing updating desired to a new
file such that it retains its relative position.  Actual generation
and version numbers are used.

//G00V00RP EXEC PGM=MYREPLAC
//INDD DD DSN=HLQ.MYGDG.G0001V00,DISP=OLD
//OUTDD DD DSN=HLQ.MYGDG.G0001V01,DISP=(NEW,CATLG)

Clark Morris
>
>-- gil
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Fastest way to read OLDEST GDG entry

[Tom Brennan]

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 to list 
every alias, and then every dsn under each alias.  I think the result 
ran in less than 5 minutes, so at the time I assumed LISTCAT wasn't 
calling CSI.  Maybe things have changed though.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Fastest way to read OLDEST GDG entry

[Steve Horein]

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 with a specific generation number while keeping
> the place in the GDG, you cataloge the new data set using the fully
> qualified DSN but replace the V00 with whatever version you like. The new
> data set will become a GDS in place and at the place of the V00 GDS. This
> new GDS will be treated as any other GDS, i.e. aged and eventually rolled
> off.
>
>
> I don't see practical use for this.
>
>
> --
> Peter Hunkeler
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

Vnn came in very handy when transferring data to a new location when a
business unit was spun off to another company. Copies of catalogs were sent
to the other data center. Historic generational data was FTPed to the
remote site to fully qualified "V01" versions, saving shipping and copying
of tapes. The business applications could refer to relative GDG and find
the data cataloged to their own tape volsers. This was several years and
two employers ago, so the specific details have gotten a bit fuzzy. I just
know both parties involved were quite satisfied, and it was a unique
learning experience crafting that solution.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: OT - another Legacy operating system

[Bernd Oppolzer]

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 professional development
of portable C programs, target platform is z/OS. The others are there
only for historic reasons, or for connectability (Linux).

The IBM DCAS disks never had any problems.

The computer is only connected locally to my laptop (only when running 
Linux),

but not exposed to the internet.

I have two such boxes at different geographic locations, 200 km distance.

Kind regards

Bernd


R.S. schrieb:


Another example: our very first computer in the company (actually, 
this sub-company) is still working as a display of some PCOMM screens. 
It is approx. 19 years old. However it's "modern" Pentium MMX with 
16MB of RAM and huge 2-3 GB HDD.





--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Fastest way to read OLDEST GDG entry

[Ted MacNEIL]

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 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 cataloge the new data set using the fully qualified DSN but replace 
the V00 with whatever version you like. The new data set will become a GDS in 
place and at the place of the V00 GDS. This new GDS will be treated as any 
other GDS, i.e. aged and eventually rolled off.


I don't see practical use for this.


--
Peter Hunkeler 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Fastest way to read OLDEST GDG entry

[Joel C. Ewing]

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 thinking
there would be an opportunity to verify things were cool before trashing
the GV00 version, but the instant the GV01 version is cataloged
the corresponding Gv00 version scratches!  The only safe way to use
this feature if the original V00 is needed to generate V01 is to first
generate a new version of the GDS under an intermediate name, verify
correctness, then copy it back with the intended GV01 GDS name,
which means at that point you could instead just as easily copy it back
under the original GV00 name. 

The only possible advantage to using Vnn > V00 to replace a V00 version
is that there is probably no time during which there is not some version
of that generation of the GDG in existence, as opposed to having that
generation disappear for the time it takes to delete the old GV00,
build the new data set, and catalog the new GV00 version.  I concede
there might be some contexts in which that slight difference in behavior
might be important. I just never encountered one in practice.
Joel C. Ewing

On 11/17/2015 08:04 PM, Ted MacNEIL wrote:
> 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 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 cataloge the new data set using the fully qualified DSN but 
> replace the V00 with whatever version you like. The new data set will become 
> a GDS in place and at the place of the V00 GDS. This new GDS will be treated 
> as any other GDS, i.e. aged and eventually rolled off.
>
>
> I don't see practical use for this.
>
>
> --
> Peter Hunkeler 
>
>


-- 
Joel C. Ewing,Bentonville, AR   jcew...@acm.org 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Fastest way to read OLDEST GDG entry

[Robert A. Rosenberg]

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.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Fastest way to read OLDEST GDG entry

[Robert A. Rosenberg]

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 faster than you process them, you should be reading them fast 
enough to keep the number under 255.


What you need to do is have your program find the oldest generation 
(you can have it look for gdg(-254) and bump to -253/etc until you 
get a FQDSN (DSN.G.V00) or use some other method to get all the 
generation names). So long as the limit is 255 and you have (lets 
say) under 200 versions, a simple manual LISTC will tell you the 
G of the earliest generation. Now submit your job passing the 
 and you are ready to go.


Now use SVC99 to allocate via the FQDSN not the relative GDG. When 
processed delete it, bump the G by 1 and  process that file. 
Eventually if you process faster than the create rate, you will get 
to and process the then current GDG(0) and get a Does Not Exist when 
you have bumped the G to GDG(+1)'s name. You can then exit. The 
only issue is when you get to G. GDG will handle this by creating 
a new G (or it may be G0001) but lising it as newer than G.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Fastest way to read OLDEST GDG entry

[Lizette Koehler]

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 GDGORDER on the JCL for z/OS V2.1 and it works great on the Base.  But
using //DDSTMT DD DISP=SHR,DSN=GDDG(0),GDGORDER=FIFO does not seem to work.

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 going to see if the LISTC could be faster than CSI.  

The process should be native to z/OS and not a vendor product.  Or
shareware/freeware is okay.

Thanks

Lizette Koehler

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Fastest way to read OLDEST GDG entry

[Robert A. Rosenberg]

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 obvious it
was a corrected version.


It is also useful when you want/need to move the file to another 
device type. I had a case, years ago, when we wanted to move from 
tape reel media to cartridges and the files needed to be kept for a 
significant period of time (past when we wanted to retire the tape 
reel device. By copying the Tape Reel V00 to a Cartridge as V01 we 
had the file remain as a GDG in its proper relative number.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

[Paul Gilmartin]

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 the command. For example, the data set name to use for RECEIVE may 
> depend on the data set XMITted. One solution might be to issue RECEIVE, trap 
> the output that contains the data set name, and END without actually 
> receiving the data set. Then construct a prompt response based the known data 
> set name, QUEUE the appropriate response, and issue RECEIVE again. Might be 
> undoable if more than one data set is waiting for RECEIVE.
> 
Terrible design, indeed.  Perhaps it was motivated by a desire to match
and surpass the worst features of the TSO OUTPUT command.

RECEIVE ought to have options:
o JOBID(JOBn)
o REPLY('string')
o QUERY (your RECEIVE; trap; END)  (like CMS NETDATA QUERY)

And it should be a prefix command in SDSF

How does RECEIVE select which spool entries to process?

But this seems to work for me:


user@OS/390.24.00: rexx "address TSO 'listcat level(...)'" |
sed -n 's/NONVSAM -.\{24\}//p' | sort
G0628V00
G0629V00
G0630V00
G0631V00
G0632V00
G0633V00
G0634V00
G0635V00
G0636V00
G0637V00
G0638V00
G0639V00
G0640V00
G0641V00
G0642V00

"sort" may be superfluous; LISTCAT seems to alphabetize its output.

On Tue, 17 Nov 2015 07:50:44 -0600, Walt Farrell wrote:
>
>CSI is a better approach than reading the output of LISTC, in my opinion, as 
>the LISTC output is not a programming interface.
>
Grrr...  IOW, you believe the output format of LISTCAT is subject to change.

Lizette seems determined to optimize a gnat with a sledgehammer.
-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

AW: Re: Fastest way to read OLDEST GDG entry

[Peter Hunkeler]

>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 confusion 
this may have caused.


--
Peter Hunkeler

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Fastest way to read OLDEST GDG entry

[J R]

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 Hunkeler 
Sent: Tuesday, November 17, 2015 4:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: 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 cataloge the new data set using the fully qualified DSN but replace 
the V00 with whatever version you like. The new data set will become a GDS in 
place and at the place of the V00 GDS. This new GDS will be treated as any 
other GDS, i.e. aged and eventually rolled off.


I don't see practical use for this.


--
Peter Hunkeler

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

AW: Re: Fastest way to read OLDEST GDG entry

[Peter Hunkeler]

> 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 cataloge the new data set using the fully qualified DSN but replace 
the V00 with whatever version you like. The new data set will become a GDS in 
place and at the place of the V00 GDS. This new GDS will be treated as any 
other GDS, i.e. aged and eventually rolled off.


I don't see practical use for this.


--
Peter Hunkeler

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

[J O Skip Robinson]

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 without processing 
the current file. You could issue RECEIVE again and get the same files (I'm 
pretty sure) in the same sequence. So on each pass, you could store the next 
file with attributes gleaned from the previous pass and then END. Repeat until 
no more files are presented. 

Pretty kludgy, but it would probably work. 

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Tuesday, November 17, 2015 12:18 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):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 the command. For example, the data set name to use for RECEIVE may 
> depend on the data set XMITted. One solution might be to issue RECEIVE, trap 
> the output that contains the data set name, and END without actually 
> receiving the data set. Then construct a prompt response based the known data 
> set name, QUEUE the appropriate response, and issue RECEIVE again. Might be 
> undoable if more than one data set is waiting for RECEIVE.
> 
Terrible design, indeed.  Perhaps it was motivated by a desire to match and 
surpass the worst features of the TSO OUTPUT command.

RECEIVE ought to have options:
o JOBID(JOBn)
o REPLY('string')
o QUERY (your RECEIVE; trap; END)  (like CMS NETDATA QUERY)

And it should be a prefix command in SDSF

How does RECEIVE select which spool entries to process?

But this seems to work for me:


user@OS/390.24.00: rexx "address TSO 'listcat level(...)'" |
sed -n 's/NONVSAM -.\{24\}//p' | sort
G0628V00
G0629V00
G0630V00
G0631V00
G0632V00
G0633V00
G0634V00
G0635V00
G0636V00
G0637V00
G0638V00
G0639V00
G0640V00
G0641V00
G0642V00

"sort" may be superfluous; LISTCAT seems to alphabetize its output.

On Tue, 17 Nov 2015 07:50:44 -0600, Walt Farrell wrote:
>
>CSI is a better approach than reading the output of LISTC, in my opinion, as 
>the LISTC output is not a programming interface.
>
Grrr...  IOW, you believe the output format of LISTCAT is subject to change.

Lizette seems determined to optimize a gnat with a sledgehammer.
-- gil


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

AW: Re: Fastest way to read OLDEST GDG entry

[Peter Hunkeler]

>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



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN