No you are correct, z/OS V1.11 does not allow VSAM to be indirectly
cataloged. However, since it was stated 3rd party products needed to be
moved off the sysres, I wanted to just expand the thought because there
might be cataloged VSAM files on the sysres as well as the indirect catalog.
z/OS V1.
I would try using DFDSS to move datasets. You would specify the origin volume
and recatalog. I don't have a system to try this on so I can't say it will
work. I would expect that IBM took these indirect volumes into account.
Jon Perryman.
>
> From: baby eklavy
FYI,
Just wanted to give a heads up to be on the lookout for OA42799.
Initiator may loop due to PDSE job end code, and cannot be cancelled or
forced. You can get a slip from PDSE L2 to abend the looping task.
APAR is not marked HIPER, so stay frosty.
Regards,
Tom Conley
-
Baby ,
I thought you are on z/os 1.11 . If that's the case , i dont think you can do
indirect cataloging on VSAM datasets .
Lizette , please correct me if am wrong .
From: Lizette Koehler
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Saturday, September 21, 2013 4
On Fri, 20 Sep 2013 12:01:44 -0400, Gerhard Postpischil wrote:
>On 9/19/2013 8:56 PM, Paul Gilmartin wrote:
>> But I'll welcome a refutation, with accompanying test cases.
>
>(Un)fortunately, you won't get one. I just ran a number of tests, and in
>each case the DUMMY allocation produced both a TI
Then I would probably write a REXX to do a LISTC ENT('nameof file') VOL
Then check to see if it was indirect
If it was, then I would write out the IDCAMS statements to change the volser
to the one you want.
Note, if the file is allocated, then it will not be able to be re-assigned
Also, if you ha
On 9/19/2013 8:56 PM, Paul Gilmartin wrote:
But I'll welcome a refutation, with accompanying test cases.
(Un)fortunately, you won't get one. I just ran a number of tests, and in
each case the DUMMY allocation produced both a TIOT and JFCB identical
to the one with DSN=NULLFILE. I tried a plai
We have our program products currently on the respack and they are
indirectly catalogued .As a part of the OS upgrade , we are trying to
separate them from the respack and put them on a new volume ..Then have the
new volume hard coded in the catalog using DEF NVSAM .
On Sat, Sep 21, 2013 at 3:3
Can you explain what you are looking to do with the information?
A LISTC command will list the information but you need to parse it to
determine what is indirect.
Lizette
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of baby eklavya
S
On Fri, 20 Sep 2013 18:46:58 +, Jousma, David wrote:
>I wouldn’t normally "jump" on something like this, but as I mentioned, I am in
>the middle
> of a maintenance cycle anyway. What's one more PTF in an already long list.
What's 10 or 20 more? Just sayin' ...:-)
On Fri, 20 Sep 20
Well all I can say seen this a lot..lack of knowledge, insufficient specs,
inability to critical think...and the worst one, not listening to heavy hitters
who know what they are doing
Scott ford
www.identityforge.com
from my IPAD
'Infinite wisdom through infinite means'
> On Sep 20, 2013, at
Hello ,
Is there a way to list out all the indirect catalogued datasets from a z/os
1.11 system ?
Regards,
Baby
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the m
On 9/20/2013 2:29 PM, Mark Zelden wrote:
No disrespect here to Tom and his "head's up", you, his problem etc.
It's nice to have a head's up on a problem. This is just something
to ponder on a Friday afternoon (and not OT either!).
I am always curious why people "jump" after a post like this
Guys,
Answer this simple question, Barbara said it best ...job executes, her sample
rc=0 , being a IEFBR14 ..I know does basically nothing ...it must drive
catalog management ..but with a 0 allocation for a PDS directory it should have
never worked according to manuals and to me common sense ..
No disrespect here to Tom and his "head's up", you, his problem etc.
It's nice to have a head's up on a problem. This is just something
to ponder on a Friday afternoon (and not OT either!).
I am always curious why people "jump" after a post like this and think to
themselves "I have to get t
I wouldn’t normally "jump" on something like this, but as I mentioned, I am in
the middle of a maintenance cycle anyway. What's one more PTF in an already
long list.
_
Dave Jousma
Assistant Vice President, Mainframe Engineering
Ron,
See Tom Ross's Share presentation slide 21 ...SR1541TR.ppt..it's a simple way
opt(full) + map look for BL=X Hth
Regards
Scott ford
www.identityforge.com
from my IPAD
'Infinite wisdom through infinite means'
> On Sep 20, 2013, at 8:54 AM, Ron Thomas wrote:
>
> Hello. We have
My read from previous remarks in this thread is that IBM's long-term
direction is toward program objects and PDSEs for all compilers, because
that sounds like the only easy way to provide new features and also
provide a common run-time environment and debugging capability across
multiple source lan
Nice timing. We are in the midst of a maintenance cycle.
_
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
-Orig
Kerneels, keep your political commentary out of this, please.
Rex
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of AbsKerneels
Sent: Friday, September 20, 2013 10:17 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Unused variables
Hi,
The idea of eliminating unreferenced variables in COBOL record
declarations is of course absurd, and fulminations against it are at
best otiose. It is always possible to construct quietist arguments
against change, any and all change; but this straw man is too
obviously so to very useful to career
I suspect that the reason why this was originally implemented this way is that
the function was added back in the day when there were only reel tapes, tape
drives were at a premium and individual ds migrate commands were infrequest, so
individual command migrations were single threaded and would
Hi,
I agree.. anybody that thinks they need to remove unused variables in a
Cobol program should rather RETIRE or vote for TED CRUZ.
Kerneels
On 9/20/2013 9:12 AM, John Gilmore wrote:
The idea of eliminating unreferenced variables in COBOL record
declarations is of course absurd, and fulmin
On 9/20/2013 2:05 AM, Mike Schwab wrote:
One suggestion I would like to make. When a dataset is deleted, a
very tiny EOF record is written to each track. Just enough so the
actual dasd unit erases all records on that track. If we were still
using real 3390s, I would suggest a track full of EOF
On Fri, 20 Sep 2013 09:00:08 -0500, Joel C. Ewing wrote:
>
>It is a common and good practice to use Copy Books to define identical
>record layouts for record structures that are accessed by multiple
>programs, even if some of the programs only need to access a single
>field in the record or just re
Joel C. Ewing wrote:
>It is a common and good practice to use Copy Books to define identical record
>layouts for record structures that are accessed by multiple programs, even if
>some of the programs only need to access a single field in the record or just
>reference the whole record as a grou
On Fri, 20 Sep 2013 08:41:56 +0200, nitz-...@gmx.net wrote:
>
>I agree with Gerhard on "In any case, IBM should be persuaded to either
>produce a JCL error or modify the directory build to write an EOF."
>I tend to the second solution: Write the EOF in any case. (In setting up my
>testcases, I ha
Tony,
The 'Java' backend has has almost certainly prevailed. Its use in the
new COBOL compiler was obviously long meditated, and it is now all but
irreversible.
John Gilmore, Ashland, MA 01721 - USA
--
For IBM-MAIN subscribe /
On 09/20/2013 08:13 AM, Elardus Engelbrecht wrote:
> Ron Thomas wrote:
>
>> Hello. We have cobol programs where we are seeing lots of unused variables.
>> Is there a way we get all the unused variables from the program?
>
> Beside eating up valuable storage during execution, is this a problem?
No. The crypto cards preceded the z machines. They were available as part of
the 9672s. There are several different ones with slightly different
capabilities. They are all on the I/O bus so they are slightly slower than the
CPACF hardware for the same operation, but they may be more secure d
On 20 September 2013 09:28, Farley, Peter x23353
wrote:
> Tim, I have to disagree in part with the statement you made below that "...
> it couldn't be avoided". It most certainly *could* have been avoided.
>
> It may have been a "... reasonable, responsible technical choice" from IBM's
> more-t
W dniu 2013-09-20 15:52, Doug Henry pisze:
On Fri, 20 Sep 2013 07:48:23 -0500, Todd Arnold wrote:
Let me add my comments on some of this discussion.
One post said "It may be ... that the recently announced "protected" clear keys can
be used without a coprocessor, increasing the security leve
On 09/20/13 09:45, John Chase wrote:
On Thu, 19 Sep 2013 12:19:37 -0400, Farley, Peter x23353 wrote:
QTE6CVllcywgdGhlIGNsZWFyLWtleSBJQ1NGIGVuY3J5cHQvZGVjcnlwdCBmdW5jdGlvbnMgKHdo
aWNoIHVzZSBvbmx5IHRoZSBDUEFDRiBDUFUgaW5zdHJ1Y3Rpb25zLCBubyBjcnlwdG8tY2FyZCBu
[. . .]
But it was readable before I q
On Fri, 20 Sep 2013 07:48:23 -0500, Todd Arnold wrote:
>Let me add my comments on some of this discussion.
>
>One post said "It may be ... that the recently announced "protected" clear
>keys can be used without a coprocessor, increasing the security level even for
>clear keys." This is not co
On Thu, 19 Sep 2013 12:19:37 -0400, Farley, Peter x23353 wrote:
>QTE6CVllcywgdGhlIGNsZWFyLWtleSBJQ1NGIGVuY3J5cHQvZGVjcnlwdCBmdW5jdGlvbnMgKHdo
>aWNoIHVzZSBvbmx5IHRoZSBDUEFDRiBDUFUgaW5zdHJ1Y3Rpb25zLCBubyBjcnlwdG8tY2FyZCBu
>[. . .]
But it was readable before I quoted it using the listserv web inter
Bernd,
IBM C/C++ and PL/I are "scheduled" to use the same backend machinery,
and it would be my guess that they will do so at about the same time;
but the actual dates associated with these scheduling decisions have
not been announced.
John Gilmore, Ashland, MA 01721 - USA
--
Funny
From: David Crayford
To: IBM-MAIN@LISTSERV.UA.EDU
Date: 09/20/2013 07:06 AM
Subject:UK NHS £10bn project failure
Sent by:IBM Mainframe Discussion List
How about this for a failed project. £10bn blowout on a doomed IT system
for the UK National Health Service
what do you expect...Gov... first failure.. Microsoft...second
failureCSC/India...oh yes--what a combo...LINUX..LINUX..LINUX...and
for something with Tera bytes of data..tell me a Mainframe--I/O subsystem
would not fit?? .
From: David Crayford
To: IBM-MAIN@LISTSERV.UA.EDU
Date: 0
Tim, I have to disagree in part with the statement you made below that "... it
couldn't be avoided". It most certainly *could* have been avoided.
It may have been a "... reasonable, responsible technical choice" from IBM's
more-than-occasionally myopic point of view, but not necessarily the bes
Elardus has given you good advice. In general, efforts of this sort
should be confined to variables defined in the working-storage
and---if unusually your shop is actually using it---local-storage
sections.
Watch out too for REDEFINES and the use of pointers for aliasing,
data-type punning, which
On 9/20/2013 7:05 AM, Staller, Allan wrote:
Check out the compiler option XREF
Hello. We have cobol programs where we are seeing lots of unused variables. Is
there a way we get all the unused variables from the program?
If you are using current COBOL, the compile option OPT(FULL) will
rem
Ron Thomas wrote:
>Hello. We have cobol programs where we are seeing lots of unused variables. Is
>there a way we get all the unused variables from the program?
Beside eating up valuable storage during execution, is this a problem?
You need to use Two Tools: XREF(FULL) and your eyes.
But, be
Check out the compiler option XREF
Hello. We have cobol programs where we are seeing lots of unused variables. Is
there a way we get all the unused variables from the program?
--
For IBM-MAIN subscribe / signoff / archive acc
Hello. We have cobol programs where we are seeing lots of unused variables. Is
there a way we get all the unused variables from the program?
Thanks
Ron T
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send e
Let me add my comments on some of this discussion.
ICSF will try to use whatever is best for any particular requested operation.
For example, if you want to do a clear-key TDES encryption of some data, it
will use the CPACF even if you also have a Crypto Express (CEX) coprocessor.
It does tha
How about this for a failed project. £10bn blowout on a doomed IT system
for the UK National Health Service
http://www.theguardian.com/society/2013/sep/18/nhs-records-system-10bn.
UK government appear to have learned their lesson by using the cloud and
open source software
http://digital.cabi
Barbara Nitz wrote:
>Not sure if that helps, but I guess you should look into defining and
>assigning a dataclas with valid space parms whenever a DSORG=PO is allocated
>with the invalid space parms I used. Or feel free to open a PMR with IBM,
>citing the doc and the obvious not-adherence to th
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of nitz-...@gmx.net
> Sent: Friday, September 20, 2013 1:14 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Allocation test
>
> > IEC999I IGC0002G,S000TBE,KAT30
> > IRX0250E System abe
> IEC999I IGC0002G,S000TBE,KAT30
> IRX0250E System abend code 0C4, reason code 0016.
> IRX0255E Abend in host command SELECT or address environment routine ISPEXEC.
> ***
I repeated Barbaras job with SPACE=(TRK,(0,0,0)) as a reference:
S000TBE DSLIST Data Set Information
Command ===>
Data
I followed this thread quietly for a long time, but now I'd like to ask
some questions
related to our site, if I'm allowed to do so:
- we are PL/1, not COBOL, but I believe that we will have this issue in
the not so
far future too, is this true?
- we have a home grown tool which does the tran
W dniu 2013-09-20 06:48, Timothy Sipples pisze:
Radoslaw Skorupka writes:
Form the other hand, inside the BOOK, inside the MCM (multi-chip-module)
there is CPACF chip (actually it's share between 2 CPs depending on the
CPC model).
A couple perhaps pedantic points:
1. Some machine models with C
Em 20/09/2013 03:42, "nitz-...@gmx.net" escreveu:
> Wow, this has snowballed. To summarize:
>
> I am allocating a DSORG=PO data set with an explicit zero space value for
> directory blocks. This data set *is* SMS-managed. The ACS routines don't
> interfere with any DCB attributes, and there is no
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Doug Henry
> Sent: Thursday, September 19, 2013 9:37 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Allocation test
>
> On Thu, 19 Sep 2013 13:50:22 -0400, Gerhard Postpischil
> w
One suggestion I would like to make. When a dataset is deleted, a
very tiny EOF record is written to each track. Just enough so the
actual dasd unit erases all records on that track. If we were still
using real 3390s, I would suggest a track full of EOF records. And
not an intensive rewrite of
55 matches
Mail list logo
