Begging time again. :-)
I am the software developer for the IPv6/VSE product.
Every time there is a new z/OS release, I need to acquire a copy of the
latest z/OS version of the EZASMI assembler macro so I can compare it to
what is used on VSE so that I can catch any compatibility issues
@LISTSERV.UA.EDU
Subject: Re: z/OS 2.2 announcement
Begging time again. :-)
I am the software developer for the IPv6/VSE product.
Every time there is a new z/OS release, I need to acquire a copy of the
latest z/OS version of the EZASMI assembler macro so I can compare it to
what is used on VSE so
partner with IBM or
have proper association with IBM.
For a customer to provide you a copy of that - might be a bad thing.
Lizette
-Original Message-
From: Tony Thigpen t...@vse2pdf.com
Sent: Aug 7, 2015 2:51 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS 2.2 announcement
Begging
In 1abe014b-9527-4921-9960-ce86e3a8b...@aim.com, on 07/29/2015
at 10:14 AM, Paul Gilmartin
000433f07816-dmarc-requ...@listserv.ua.edu said:
o Must a symbol replace an entire qualifier,
No.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see
In 4520252983585371.wa.paulgboulderaim@listserv.ua.edu, on
07/30/2015
at 08:51 AM, Paul Gilmartin
000433f07816-dmarc-requ...@listserv.ua.edu said:
It appears to me that
DEFINE ALIAS (NAME(aliasname) RELATE(entryname) ... )
DEFINE PATH (NAME(entryname) PATHENTRY(entryname)
On Thu, 30 Jul 2015 06:25:01 -0500, Walt Farrell wrote:
A VSAM PATH _can_ be the same as a non-VSAM ALIAS. However, it also can be
different.
For keyed VSAM files, if you specify the PATHENTRY keyword when defining a
PATH, you can specify that the PATH should use an alternate index. At that
Subject: Re: Aliases (was: z/OS 2.2 announcement)
On 2015-07-29, at 15:59, Staller, Allan wrote:
PATH does not equal ALIAS in VSAM...
How are they different? In my experience they're just commands with different
names that do the same thing.
snip
BTW, is there any good reason
On Thu, 30 Jul 2015 12:57:35 +, Staller, Allan wrote:
RTFM...
From:
z/OS DFSMS Access Method Services Commands
SC23-6846-01
It appears to me that
DEFINE ALIAS (NAME(aliasname) RELATE(entryname) ... )
DEFINE PATH (NAME(entryname) PATHENTRY(entryname) ,,, )
...
perform
On Wed, 29 Jul 2015 22:57:53 -0600, Paul Gilmartin paulgboul...@aim.com wrote:
On 2015-07-29, at 15:59, Staller, Allan wrote:
PATH does not equal ALIAS in VSAM...
How are they different? In my experience they're just commands
with different names that do the same thing.
A VSAM PATH _can_
:14 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Aliases (was: z/OS 2.2 announcement)
On 2015-07-29, at 09:59, Skeldum, William wrote:
A symbolic symbol can be defined as: 'NULL='.
I then defined an alias as follows:
DEFINE ALIAS (NAME(TEST.NEW.JCL.CNTL)
SYMBOLICRELATE
Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Paul Gilmartin
Sent: Wednesday, July 29, 2015 9:07 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Aliases (was: z/OS 2.2 announcement)
On Wed, 29 Jul 2015 14:38:50 +, Staller, Allan wrote:
...
Once *EVERYTHING has moved to the alias
On 2015-07-29, at 09:59, Skeldum, William wrote:
A symbolic symbol can be defined as: 'NULL='.
I then defined an alias as follows:
DEFINE ALIAS (NAME(TEST.NEW.JCL.CNTL) SYMBOLICRELATE(TEST.NULL.JCL.CNTL))
When I reference TEST.NEW.JCL.CNTL in DSLIST (ISPF 3.4) TEST.JCL.CNTL is
displayed.
PATH does not equal ALIAS in VSAM...
snip
BTW, is there any good reason that an alias for a non-VSAM data set is called
an ALIAS while an alias for a VSAM data set is called a PATH?
(Might some object have both, in which case the distinction is meaningful?)
/snip
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
On Behalf Of Paul Gilmartin
Sent: Wednesday, July 29, 2015 8:07 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Aliases (was: z/OS 2.2 announcement)
Is there a utility to enumerate all ALIASes to a given
On Wed, 29 Jul 2015 11:26:58 -0700, retired mainframer wrote:
LISTCAT ENT(dsn) ALL.
If dsn is not VSAM, the RELATED field in the output will show all aliases, if
any. If dsn is VSAM, the PATH field will show any aliases. If dsn is a path
or alias, the RELATED field will show the true name of
Just one problem with your implementation plan. Most sites I know would not
want to recompile every COBOL program they run into a PDSE, then do a rename
swap to implement. IEFOPZxx is great solution to this problem.
You don't need to recompile them to store them in a PDSE. You can just
@LISTSERV.UA.EDU] On
Behalf Of Fred van der Windt
Sent: Tuesday, July 28, 2015 10:40 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS 2.2 announcement
This was discussed at the vendor TDM but I think I am not talking out of
school here now that this is announced ...
One obstacle to customers
On Wed, 29 Jul 2015 14:38:50 +, Staller, Allan wrote:
...
Once *EVERYTHING has moved to the alias, the original dataset can be deleted
and the process repeated in the other direction.
This make take several (days, weeks, months,) depending on the
installations policies and
On 2015-07-29, at 08:13, Staller, Allan wrote:
Better yet, copy PDS to PDSE and define a dataset alias
But be careful:
o Don't you need at least to uncatalog the PDS to define the alias?
Can this be done while an ENQ exists? I suspect, yes.
o Initiator ENQ works differently, perhaps
Yes you can.
snip
o Don't you need at least to uncatalog the PDS to define the alias?
Can this be done while an ENQ exists? I suspect, yes.
/snip
Once *EVERYTHING has moved to the alias, the original dataset can be deleted
and the process repeated in the other direction.
This make take
Better yet, copy PDS to PDSE and define a dataset alias
snip
In a large shop the old PDS would be in continuous use and therefore
difficult to swap out.
A shop must be prepared to do this in the event of hardware replacement.
This sounds like a good argument for a facility to rename a
On Wed, 29 Jul 2015 06:17:31 -0700, Charles Mills wrote:
In a large shop the old PDS would be in continuous use and therefore
difficult to swap out.
A shop must be prepared to do this in the event of hardware replacement.
This sounds like a good argument for a facility to rename a data set
List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
On Behalf Of Ed Jaffe
Sent: Tuesday, July 28, 2015 5:52 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS 2.2 announcement
On 7/28/2015 2:17 PM, Mike Schwab wrote:
Maybe they would apply the balance toward an earlier purchase?
In my experience
IEFOPZxx allows you to define pairs of libraries, where the paired library
is concatenated ahead of the original. F'rinstance:
//STEPLIB DD DISP=SHR,DSN=GOODOLD.COBOLPDS.LOADLIB
In IEFOPZxx, we define DUMBNEW.COBOL5.PDSELOAD as a pair to
GOODOLD.COBOLPDS.LOADLIB. So whenever the
This was discussed at the vendor TDM but I think I am not talking out of
school here now that this is announced ...
One obstacle to customers converting to COBOL 5 is the requirement that the
resulting executable programs reside in a PDSE. The customer presumably has
thousands of jobs
On Tue, 28 Jul 2015 10:25:59 -0500, Tom Marchant wrote:
z?OS 2.2 was announced today. It requires a Z10 or newer processor.
http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?subtype=cainfotype=anappname=iSourcesupplier=897letternum=ENUS215-267#availx
http://preview.tinyurl.com/p64hluq
Thanks.
z?OS 2.2 was announced today. It requires a Z10 or newer processor.
http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?subtype=cainfotype=anappname=iSourcesupplier=897letternum=ENUS215-267#availx
http://preview.tinyurl.com/p64hluq
--
Tom Marchant
On 7/29/2015 1:40 AM, Fred van der Windt wrote:
This was discussed at the vendor TDM but I think I am not talking out of school
here now that this is announced ...
One obstacle to customers converting to COBOL 5 is the requirement that the
resulting executable programs reside in a PDSE. The
@LISTSERV.UA.EDU]
On Behalf Of Cheryl Watson
Sent: Tuesday, July 28, 2015 2:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS 2.2 announcement
Another reason to move to a newer processor is the reduction on software
prices. Even if you had to pay double maintenance for a while, and I agree
of
service next year. HW maintnenace is pre-paid on the z9 until June 2017
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
On Behalf Of Tom Marchant
Sent: Tuesday, July 28, 2015 8:26 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: z/OS 2.2 announcement
z
I'd plan on putting in the order for zOS 2.1 not much later than mid-August.
Mark Jacobs
Gibney, David Allen,Jr mailto:gib...@wsu.edu
July 28, 2015 at 5:10 PM
Looks nice, won't run on my z9. I just spent awhile trying to find the
definitive statement as to what date z/OS 2.1 will be withdrawn
@LISTSERV.UA.EDU]
On Behalf Of Tom Marchant
Sent: Tuesday, July 28, 2015 8:26 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: z/OS 2.2 announcement
z?OS 2.2 was announced today. It requires a Z10 or newer processor.
https://urldefense.proofpoint.com/v1/url?u=http://www-
01.ibm.com/common/ssi/cgi
@LISTSERV.UA.EDU] On
Behalf Of Frank Swarbrick
Sent: Tuesday, July 28, 2015 1:28 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS 2.2 announcement
I found this to be interesting, but I don't quite understand it:
z/OS V2.2 is designed to
support a new IEFOPZxx parmlib member in which you can specify
On 7/28/2015 4:27 PM, Frank Swarbrick wrote:
I found this to be interesting, but I don't quite understand it:
z/OS V2.2 is designed to
support a new IEFOPZxx parmlib member in which you can specify pairs
of partitioned (PDS and PDSE) data sets. In each pair, you can specify
one that is to be
...@listserv.ua.edu
Subject: z/OS 2.2 announcement
To: IBM-MAIN@LISTSERV.UA.EDU
z?OS 2.2 was announced today. It requires a Z10 or newer processor.
http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?subtype=cainfotype=anappname=iSourcesupplier=897letternum=ENUS215-267#availx
http
-M213749N23348W43-Z966844T77753Y85
Lizette
-Original Message-
From: Gibney, David Allen,Jr gib...@wsu.edu
Sent: Jul 28, 2015 2:10 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS 2.2 announcement
Looks nice, won't run on my z9. I just spent awhile trying to find the
definitive statement
On 7/28/2015 2:17 PM, Mike Schwab wrote:
Maybe they would apply the balance toward an earlier purchase?
In my experience. they will do exactly that. We have *never* had a
problem getting credited for remaining time on an existing pre-paid IBM
CPU, DASD or Tape maintenance contract as part of
@LISTSERV.UA.EDU] On Behalf
Of Ed Jaffe
Sent: Tuesday, July 28, 2015 5:52 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS 2.2 announcement
On 7/28/2015 2:17 PM, Mike Schwab wrote:
Maybe they would apply the balance toward an earlier purchase?
In my experience. they will do exactly that. We have
Don't worry, I'm already thinking about other uses. :-)
Thanks!
Date: Tue, 28 Jul 2015 16:49:31 -0400
From: pinnc...@rochester.rr.com
Subject: Re: z/OS 2.2 announcement
To: IBM-MAIN@LISTSERV.UA.EDU
On 7/28/2015 4:27 PM, Frank Swarbrick wrote:
I found this to be interesting, but I don't
39 matches
Mail list logo
