Bob Shannon wrote:
I've never heard anyone claim PDSEs were "great". Even "good" would be a
stretch. Making SMS a requirement for PDSEs was a marketing decision,
not a technical one. Support for a non-SMS environment has nothing to do
with current problems. PDSEs were buggy for a long time after
>PDSE's were great until IBM decided to support them as non-SMS
constructs.
>They took an (elegant) implementation and screwed it up with dual
code->streams and other unnatural acts to force it into that
environment.
I've never heard anyone claim PDSEs were "great". Even "good" would be a
stretch.
Well, I AM a product developer, have been for years now, and I get
along just fine without them, thank you very much.
And you're right about big directories, too. Among other things, you
never know when you're going to need the directory space in rder to
use the RESTORE function of PDS. I al
>Would there have been any other way to create program objects in temporary
>data sets, which I consider an important facility
Not being a product developer, I have no need for that facility, but I would
use PDSE's (grudgingly) when I have no choice.
In a lot of cases, it's Hobson's choice:
1.
One more thing that I find interesting.
A quick trip through the archives indicates that using TRSMAIN on tape datasets
yields the same illuminating error.
I'd like to someday know what that program is doing.
Bob
David Shein wrote:
Oh, and one more thing!
The only reason we solved this pro
>Like you, I never create or use one now if I can possibly help it. DASD is
>cheap and the aggravation isn't worth it.
And, I create huge directorys.
Minimum of 1 cylinder, usually 5.
-
Too busy driving to stop for gas!
--
F
Oh, and one more thing!
The only reason we solved this problem was that we HAPPENED to
notice, in passing, that the original data set was a PDSE. If we
hadn't, we would probably still be searching for the answer.
Yes, the restriction is documented, but for that to be of any help,
it has to
Been a few weeks since there has been a spleen venting session re PDSE.
And I get two posts about "niggles" with 'em on the same day.
Unsurprisingly, more and more vendors are shipping them. Some because of
functionality, some of them because it's the "thing to do".
Pity the poor customer.
Shane
Very good question. If anyone can find the answer, please share.
- David
.. the only reference I see to space allocation of temporary
data sets is:
Updates to TRSMAIN
[ ... ]
4.11 2004-11-29
[ ... ]
+ Allow overriding the temporary dataset space allocatio
In a recent note, Ted MacNEIL said:
> Subject: Re: PDSE [WAS: TERSE (TRSMAIN)]
>
> >I avoid PDSE's like the plague.
>
> PDSE's were great until IBM decided to support them as non-SMS constructs.
> They took an (elegant) implementation and screwed it up wit
I understand you perfectly. In fact, it sounds as though your
experience has been more favorable than mine. They used to bite me
regularly even before the SMS restriction was relaxed. Like you, I
never create or use one now if I can possibly help it. DASD is cheap
and the aggravation isn't
In a recent note, Bob Rutledge said:
> Subject: Re: TERSE (TRSMAIN)
>
> Well, in fairness, the cited documentation stated the restriction.
>
In the document you cited:
http://techsupport.services.ibm.com/390/trsmain.html
.. the only reference I see to space allocation
>I avoid PDSE's like the plague.
PDSE's were great until IBM decided to support them as non-SMS constructs.
They took an (elegant) implementation and screwed it up with dual code-streams
and other unnatural acts to force it into that environment.
When they first came out, I used them all the tim
Yes it did. Acknowledged. That could have saved us some time, but
it is no excuse for the real problem. Now we have to use four steps
instead of two to handle these: copy to a PDS, terse the PDS, unterse
the PDS, copy to a PDSE.
Like I said, one more exception to remember. If PDSE's had ev
Well, in fairness, the cited documentation stated the restriction.
Bob
Paul Gilmartin wrote:
In a recent note, David Shein said:
Date: Wed, 21 Mar 2007 15:35:30 -0700
It isn't OUTFILE that's failing. It's a work file named SYS1,
and there doesn't seem to be any (obvious) way to
In a recent note, David Shein said:
> Date: Wed, 21 Mar 2007 15:35:30 -0700
>
> It isn't OUTFILE that's failing. It's a work file named SYS1,
> and there doesn't seem to be any (obvious) way to control the
> allocation of workfiles. If you allocate SYS1, he ignores it and
> trie
Nope. However, the problem is solved: TRSMAIN doesn't support PDSEs,
and this is one. Copied the data to a "real" PDS and tersed
that. Can't change the original data set, it's a system file.
One more bullet to add to my list of reasons why I hate PDSE's. One
more exception to remember.
-
Are you by any chance trying to unterse a tape file?
Bob
David Shein wrote:
It isn't OUTFILE that's failing. It's a work file named SYS1, and
there doesn't seem to be any (obvious) way to control the allocation of
workfiles. If you allocate SYS1, he ignores it and tries to
allocate
It isn't OUTFILE that's failing. It's a work file named SYS1,
and there doesn't seem to be any (obvious) way to control the
allocation of workfiles. If you allocate SYS1, he ignores it and
tries to allocate his own SYS2 with the same failure. Thus, my
"where is it documented" que
Thanx. That shows what I feared it would, i.e., no way to control
work file allocations. At least nothing that is documented. Good try.
- David
At 06:27 PM 3/21/2007 -0400, you wrote:
David Shein wrote:
Does anyone know where (or even whether) TRSMAIN is documented?
http://techsupport.s
David Shein wrote:
Does anyone know where (or even whether) TRSMAIN is documented?
http://techsupport.services.ibm.com/390/trsmain.html
Bob
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EM
Added REGION=0M and it made no difference. Good thought, anyway.
- David
At 06:19 PM 3/21/2007 -0400, you wrote:
>We are trying to unterse a large data set and failing with B378 abends
on >VIO
Do you know what is being allocated to VIO? I just allocate a large
output dataset to disk and have
>We are trying to unterse a large data set and failing with B378 abends
on >VIO
Do you know what is being allocated to VIO? I just allocate a large
output dataset to disk and have never encountered a problem with VIO. An
output dataset that is ten times the size of the input should handle
most cas
EDU
cc
Subject
Re: TERSE (TRSMAIN)
Sorry for the typo -- that should read "B37", not "B378". Finger
check. Otherwise the post stands as written.
- David
At 02:52 PM 3/21/2007 -0700, you wrote:
>We are trying to unterse a large data set and failing with B378 abends
Sorry for the typo -- that should read "B37", not "B378". Finger
check. Otherwise the post stands as written.
- David
At 02:52 PM 3/21/2007 -0700, you wrote:
We are trying to unterse a large data set and failing with B378 abends on VIO.
Does anyone know where (or even whether) TRSMAIN is
We are trying to unterse a large data set and failing with B378 abends on VIO.
Does anyone know where (or even whether) TRSMAIN is documented?
Or, failing that, does anyone know how to get around this allocation
barrier? We have tried adding big page data sets, allocating work
files in JCL, e
26 matches
Mail list logo
