On 28 Jan 2010 05:54:14 -0800, r.skoru...@bremultibank.com.pl (R.S.)
wrote:
BTW: The above is only one of possible scenarios. Another one is someone
simply subscribed to the list just for such purpose. What's sad: there
is no reasonable way to fight against it: everyone can subsribe to the
On 22 Jan 2010 12:26:56 -0800, john.mck...@healthmarkets.com (McKown,
John) wrote:
Ah! I intepreted beyond trivial as not trivial as the direction of travel
was not specified. My bad.
Not as, quadrivial?
--
For IBM-MAIN
-Subs nearly painless I could
rewrite all this ASM-Subs and use dynamic Saveareas but I wonder if just
using REUS=NONE would do the same job...
So bring it to a question: What is the scope of the REUS-Option?
(Sub)Task-Level? Then using REUS=NONE would bring up a new copy of the
ASM-Stubs for every
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Michael Knigge
Sent: Tuesday, July 07, 2009 5:13 AM
To: IBM-MAIN@bama.ua.edu
Subject: Question about REUS=NONE
SNIPPAGE
But I wonder how to migrate the ASM-Subs nearly painless I could
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Michael Knigge
Sent: Tuesday, July 07, 2009 6:13 AM
To: IBM-MAIN@bama.ua.edu
Subject: Question about REUS=NONE
Snipped
Now we are just about 13 years later and I have to convert
Farley, Peter x23353 wrote:
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Michael Knigge
Sent: Tuesday, July 07, 2009 6:13 AM
To: IBM-MAIN@bama.ua.edu
Subject: Question about REUS=NONE
Snipped
Now we are just about 13 years later
-Original Message-
From: IBM Mainframe Discussion List
[mailto:ibm-m...@bama.ua.edu] On Behalf Of Steve Comstock
Sent: Tuesday, July 07, 2009 9:44 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Question about REUS=NONE
snip
You need to be careful with dynamic call vs. attaching
each subtask).
But I wonder how to migrate the ASM-Subs nearly painless I could
rewrite all this ASM-Subs and use dynamic Saveareas but I wonder if just
using REUS=NONE would do the same job...
So bring it to a question: What is the scope of the REUS-Option?
(Sub)Task-Level? Then using
In one sense as someone who is sem-retired, I have no vested interest
other than as someone who believes that COBOL still MAY have a future.
My belief is that in order for that future to exist, COBOL programs or
routines have to be able to exist in a 64 bit Websphere address space,
communicate
On Mon, 26 Jan 2009 13:49:24 -0800, Tom Ross tmr...@stlvm20.vnet.ibm.com
wrote:
In one sense as someone who is sem-retired, I have no vested interest
other than as someone who believes that COBOL still MAY have a future.
My belief is that in order for that future to exist, COBOL programs or
On the other hand,
we know that we need to do AMODE 64 COBOL someday, but not one customer
has asked IBM COBOL development to do it yet.
I find that difficult to believe. Perhaps the validity of your assertion
depends on one's definition of the word asked.
True! My definitions...
On 23 Jan 2009 17:43:53 -0800, in bit.listserv.ibm-main you wrote:
Tom Ross wrote:
XML features of COBOL have been the most quickly adopted new features of
COBOL in my 25 years of IBM COBOL development. We shipped AMODE 31 in
1984, Intrinsic Functions in 1991, OO in 1995, but many users are
And may I ask how many customers actually asked for 64 bit C/C++ or Java ?
Mohammad
On Thu, 22 Jan 2009 16:10:33 -0800, Tom Ross
tmr...@stlvm20.vnet.ibm.com wrote:
snip
documents today! We can't keep up with demand. On the other hand,
we know that we need to do AMODE 64 COBOL someday, but not
] On
Behalf Of Mohammad Khan
Sent: Friday, January 23, 2009 9:08 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: AIX gets 64 bit COBOL but still none for Z/os ...
And may I ask how many customers actually asked for 64 bit C/C++ or Java
?
Mohammad
On Thu, 22 Jan 2009 16:10:33 -0800, Tom Ross
tmr
R.S. wrote:
Is there any reason to have 64-bit COBOL on z/OS ?
Of course except satisfaction when watching AMODE 64 in ISPF member
list...
Perhaps not in a homogeneous programming world in which COBOL is your
only programming language. But, don't you need 64-bit support to be able
to share
Tom Ross wrote:
XML features of COBOL have been the most quickly adopted new features of
COBOL in my 25 years of IBM COBOL development. We shipped AMODE 31 in
1984, Intrinsic Functions in 1991, OO in 1995, but many users are still
running below the line, don't use built-in functions, never
Mohammad Khan wrote:
And may I ask how many customers actually asked for 64 bit C/C++ or Java ?
Mohammad
Vendors... Of course, 64 bit C/C++ was a high priority because a lot of
middleware is written in those languages, WAS, MQ etc. And 64 bit Java
is a no brainer considering the memory
Clark Morris writes:
Why does COBOL need XML handling?
Because many customers wanted it and filed excellent requirements details
with IBM, through SHARE and other avenues. (Which now means we've come full
circle, again, in this discussion thread. :-))
Question back to you: why does COBOL need
I'll throw in the thought that the experiences with similar things from
the past - like Data Windowing Services - may be relevant...
What did customers like or dislike about them? My suspicion is they were
too difficult to use for most people and didn't necessarily provide that
much benefit.
Meanwhile, COBOL customers are beating us up about XML validation,
XMLSS, Unicode, useability features and many other things besides
AMODE 64 COBOL. We have to do it all right?
Why does COBOL need XML handling? Is it generating in line code as
opposed to setting up calls as is the case for CICS
IBM intends to keep extending z/SO COBOL for many years to come!
We have been exploring what it would take to get AMODE 64 COBOL
on z/OS for years. Coordination between all of the products is in
progress. We could ship a compiler that could produce AMODE 64
object code in just a few years (it
On 21 Jan 2009 15:10:26 -0800, in bit.listserv.ibm-main you wrote:
IBM intends to keep extending z/SO COBOL for many years to come!
We have been exploring what it would take to get AMODE 64 COBOL
on z/OS for years. Coordination between all of the products is in
progress. We could ship a
Howard Brazee writes:
What I don't get is why this is an issue for IBM
I don't know how much I can say about this issue, but what the heck, I
speak only for myself.
I think a lot of people are over-analyzing this, thinking there's something
political, religious, or whatever. Like a C/C++ fan
On 15 Jan 2009 01:03:50 -0800, e99...@jp.ibm.com (Timothy Sipples)
wrote:
That's why it's important that customers keep IBM informed on this, to help
guide these decisions and prioritize requirements.
Ideally (for us), IBM would be in the business of helping its existing
customers. But getting
On Wed, 14 Jan 2009 15:32:00 +0900, Timothy Sipples e99...@jp.ibm.com wrote:
Ed Gould writes:
Yes there is. Just last month the *OLD* table problem popped up.
User needs LARGE in storage table (10G). Her only option was to.
write the file to a VSAM data set and do inquiries on it with
I/O. The
Clark Morris cfmpub...@ns.sympatico.ca wrote:
Dave Rivers wrote:
Just to add a quick note to that, a popular option
for our users is to write a quick-n-dirty C function
to handle the 64-bit data (directly callable from 31-bit
COBOL).
Since there is NOTHING in the 1985 COBOL standard, let
I understand your desire for 64-bit COBOL.
I would suggest that if you WANT 64-bit COBOL, that you have your company
submit a marketing requirement and reference SHARE requirement:
SSLNGC0413607 Support 64 bit and web-oriented development in COBOL
Unless you want a 64-bit COBOL that can't
On 14 Jan 2009 10:50:31 -0800, wmkl...@ix.netcom.com (Bill Klein)
wrote:
I understand your desire for 64-bit COBOL.
I would suggest that if you WANT 64-bit COBOL, that you have your company
submit a marketing requirement and reference SHARE requirement:
What I don't get is why this is an issue
--- On Fri, 1/9/09, R.S. r.skoru...@bremultibank.com.pl wrote:
From: R.S. r.skoru...@bremultibank.com.pl
Subject: Re: AIX gets 64 bit COBOL but still none for Z/os ...
To: IBM-MAIN@bama.ua.edu
Date: Friday, January 9, 2009, 7:56 AM
Is there any reason to have 64-bit
COBOL on z/OS
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Ed Gould
Sent: Tuesday, January 13, 2009 11:02 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: AIX gets 64 bit COBOL but still none for Z/os ...
SNIPPAGE
Assembler is dead (or at least almost
On Tue, 13 Jan 2009 09:02:03 -0800, Ed Gould ps2...@yahoo.com wrote:
Yes there is. Just last month the *OLD* table problem popped up. User needs
LARGE in storage table (10G). Her only option was to write the file to a
VSAM data set and do inquiries on it with I/O. The run time (even with CI's
in
Ed Gould wrote:
--- On Fri, 1/9/09, R.S. r.skoru...@bremultibank.com.pl wrote:
From: R.S. r.skoru...@bremultibank.com.pl
Subject: Re: AIX gets 64 bit COBOL but still none for Z/os ...
To: IBM-MAIN@bama.ua.edu
Date: Friday, January 9, 2009, 7:56 AM
Is there any reason to have 64-bit
COBOL on z
On Tue, 13 Jan 2009 16:52:07 -0500, Thomas David Rivers riv...@dignus.com
wrote:
Ed Gould wrote:
--- On Fri, 1/9/09, R.S. r.skoru...@bremultibank.com.pl wrote:
From: R.S. r.skoru...@bremultibank.com.pl
Subject: Re: AIX gets 64 bit COBOL but still none for Z/os ...
To: IBM-MAIN@bama.ua.edu
Date
Yes thanks bit as others have mentions C isn't licensed at the installation and
the number of COBOL programmers who do know c is less than the number of
Assembler types out there. I have found that the senior COBOL types have over
the years have picked up assembler (little bits) as it is
Ed Gould writes:
Yes there is. Just last month the *OLD* table problem popped up.
User needs LARGE in storage table (10G). Her only option was to.
write the file to a VSAM data set and do inquiries on it with
I/O. The run time (even with CI's in memory) was about 4 hours..
She did a rough quicky
On 9 Jan 2009 19:06:48 -0800, cfmpub...@ns.sympatico.ca (Clark Morris)
wrote:
If COBOL is still considered strategic and going forward rather than
something to be maintained until you can migrate to the brave new
world of Java, C#, New Vision, etc., then 64 bit is needed to support
IBM strategy.
The situation is even more ironic with Java architects / designers (with active
endorsement from IBM) - they WON'T USE database features at all because it
conflicts with OOP design principles. From what I have seen they reduce DB2
to an index file server with transactions and logging. I guess
John McKown pisze:
On Fri, 9 Jan 2009 16:11:36 -0500, David Andrews d...@lists.duda.com wrote:
On Fri, 2009-01-09 at 14:11 -0600, John McKown wrote:
OK - how much money, in the form of licensing cost, are you willing to pay
to get 64 bit addressing in COBOL?
What I already pay today, for a
On Sat, 10 Jan 2009, R.S. wrote:
snip
How much will you pay for the enhancements you don't need?
A very good point! In our case, we could still run effectively using VS
COBOL II, CICS/TS 1.3, and z/OS 1.6. We are basically stabilized at that
level. If the costs today were what they were back
Is there any reason to have 64-bit COBOL on z/OS ?
Of course except satisfaction when watching AMODE 64 in ISPF member list...
--
Radoslaw Skorupka
Lodz, Poland
--
BRE Bank SA
ul. Senatorska 18
00-950 Warszawa
www.brebank.pl
Sąd Rejonowy dla m. st. Warszawy
XII Wydział Gospodarczy Krajowego
On Fri, 9 Jan 2009 14:56:51 +0100, R.S. r.skoru...@bremultibank.com.pl wrote:
Is there any reason to have 64-bit COBOL on z/OS ?
Of course except satisfaction when watching AMODE 64 in ISPF member list...
--
Radoslaw Skorupka
Lodz, Poland
I've often wondered this as well. 31 bit addressing
Is there any reason to have 64-bit COBOL on z/OS ?
Parsing or generating _really_ _big_ XML data streams?
In a CICS Web Services provider scenario, one could posit a very large 01
level, only some of which gets filled in for any one request...
01 Work-Areas.
05 Some-Table-Nb
There are some cases that do need it. If a program is processing XML or
Large OBjects ( LOBs - document images, video, audio ) the memory use
baloons up pretty fast. If these are being used under CICS multiply by the
number of concurrent transactions. There is only so much that you can fit
I've often wondered this as well. 31 bit addressing gives the possibility of
more than 1 Gib of data for an application. What __user written__
application would use more than this?
All you'll ever need is 640K!
16M is more than enough memory.
Close the patent office. Everything that can be
In a message dated 1/9/2009 9:08:10 A.M. Central Standard Time,
craig.schneiderw...@dot.state.wi.us writes:
videos in DB2 BLOBs and serves them via CICS Web Services COBOL
applications. But I don't know of any such business.
CNBC was reporting the Porn industry is asking for several
On Fri, 9 Jan 2009 15:58:23 +, Ted MacNEIL eamacn...@yahoo.ca wrote:
I've often wondered this as well. 31 bit addressing gives the possibility of
more than 1 Gib of data for an application. What __user written__
application would use more than this?
All you'll ever need is 640K!
16M is more
In 496757a3.4080...@bremultibank.com.pl, on 01/09/2009
at 02:56 PM, R.S. r.skoru...@bremultibank.com.pl said:
Is there any reason to have 64-bit COBOL on z/OS ?
Yes.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see http://patriot.net/~shmuel/resume/brief.html
We
BTW - I prefer solid examples for current need, not histrionics.
Call it histrionics if you like.
But, just because we don't need it today, doesn't mean we won't need it
tomorrow.
This field already suffers from short-sightedness.
Please don't add more.
My point was think ahead.
Don't get stuck
discussion, as long as LE cannot mix 64Bit and 31Bit modules,
what is the benefit?
-Original Message-
From: Schneiderwent, Craig - DOT craig.schneiderw...@dot.state.wi.us
To: IBM-MAIN@bama.ua.edu
Sent: Fri, 9 Jan 2009 3:36 pm
Subject: Re: AIX gets 64 bit COBOL but still none for Z/os
On Fri, 9 Jan 2009 19:50:07 +, Ted MacNEIL eamacn...@yahoo.ca wrote:
BTW - I prefer solid examples for current need, not histrionics.
Call it histrionics if you like.
But, just because we don't need it today, doesn't mean we won't need it
tomorrow.
This field already suffers from
If I implied that 64 bit addressing in COBOL is a unwanted / unneeded
enhancement, I gave the wrong impression and I hope that I have corrected it.
I just wonder about the relative importance of 64 bit addressing versus other
COBOL enhancements.
That's a different issue.
I thought you didn't
Denis Gäbler denisgaeb...@netscape.net wrote in message
news:8cb40acc0589804-abc-...@webmail-dx19.sysops.aol.com...
For video on demand databases are too slow.
You would use a streaming server, for which I don't know any available for
System z OS except VM Stairs.
In addition, a streaming
On 9 Jan 2009 09:01:19 -0800, joa...@swbell.net (John McKown) wrote:
Why not go whole hog? Skip 64 bit addressing entirely. Go to 128 bit. Why
not? After all the i series machines are already using 128 bit addressing.
And all their languages support it. IBM claims that the i has the largest
On Fri, 2009-01-09 at 14:11 -0600, John McKown wrote:
OK - how much money, in the form of licensing cost, are you willing to pay
to get 64 bit addressing in COBOL?
What I already pay today, for a current COBOL compiler backed by
developers and support staff.
--
David Andrews
A. Duda and Sons,
On Fri, 9 Jan 2009 16:11:36 -0500, David Andrews d...@lists.duda.com wrote:
On Fri, 2009-01-09 at 14:11 -0600, John McKown wrote:
OK - how much money, in the form of licensing cost, are you willing to pay
to get 64 bit addressing in COBOL?
What I already pay today, for a current COBOL compiler
On Fri, 9 Jan 2009 14:08:29 -0700, Howard Brazee howard.bra...@cusys.edu
wrote:
snip
There are sites that will benefit significantly from this change. And
it's a change that could make IBM better market its product (which
indirectly helps us).
Of course, maybe IBM sees its future in AIX instead
On 9 Jan 2009 12:13:51 -0800, in bit.listserv.ibm-main you wrote:
On Fri, 9 Jan 2009 19:50:07 +, Ted MacNEIL eamacn...@yahoo.ca wrote:
BTW - I prefer solid examples for current need, not histrionics.
Call it histrionics if you like.
But, just because we don't need it today, doesn't mean we
Who says COBOL doesn't get tweaks?
Track this topic Print story Post comment
IBM Power/AIX machines get 64-bit support - finally
By Timothy Prickett Morgan • Get more from this author
Posted in Enterprise, 7th January 2009 20:23 GMT
Business whitepaper - Virtualization: the four key cost savings
On Thu, 17 Jan 2008 17:31:21 -0600, Mark Zelden wrote:
Is
there a system determined BLKSIZE on a PATH= DD statement, or is the sort
program left to deal with it?
see above
For a while, SDB always set BLKSIZE for PATH= to 80. This was much fixed
as a side effect of an APAR directed to JES,
On Jan 16, 2008, at 11:55 AM, Rick Fochtman wrote:
---snip---
I have not done a merge in *YEARS*, having said that I believe
(even if you concatenate) each concatenation has to be in a
higher sequence than the file ahead of the concatenation (all
records
On Thu, 17 Jan 2008 17:25:43 -0500, Tom Russell [EMAIL PROTECTED] wrote:
Date:Tue, 15 Jan 2008 12:16:53 -0600
From:Mark Zelden [EMAIL PROTECTED]
Subject: Re: DFSORT question MERGE w/SUM FIELDS=NONE
This worked (SYNCSORT). But I did have to specify LRECL, BLKSIZE,
and RECFM on the DDs
Date:Tue, 15 Jan 2008 12:16:53 -0600
From:Mark Zelden [EMAIL PROTECTED]
Subject: Re: DFSORT question MERGE w/SUM FIELDS=NONE
This worked (SYNCSORT). But I did have to specify LRECL, BLKSIZE,
and RECFM on the DDs or I got RC16:
//SORTEXEC PGM=SORT
//SYSOUT DD SYSOUT
Ed Gould wrote on 01/15/2008 09:07:38 PM:
I believe (even
if you concatenate) each concatenation has to be in a higher
sequence than the file ahead of the concatenation (all records still
must be in the right sequence) so (if) you can concatenate the
records must be in sequence. I hope I said
---snip---
I have not done a merge in *YEARS*, having said that I believe (even if
you concatenate) each concatenation has to be in a higher sequence
than the file ahead of the concatenation (all records still must be in
the right sequence) so (if) you can
The manual is unclear on this. First question: Is this supported? I.e.
will SORTOUT contain only one of the records with the duplicate key?
Second question: Which record will be kept? Random, the one read from
the lowest SORTINnn or the one read from the highest SORTINnn DD
statement?
--
John
On Tue, 15 Jan 2008 10:25:23 -0600, McKown, John wrote:
The manual is unclear on this. First question: Is this supported? I.e.
will SORTOUT contain only one of the records with the duplicate key?
Second question: Which record will be kept? Random, the one read from
the lowest SORTINnn or the one
-Original Message-
From: IBM Mainframe Discussion List
[mailto:[EMAIL PROTECTED] On Behalf Of Dave Kopischke
Sent: Tuesday, January 15, 2008 11:00 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: DFSORT question MERGE w/SUM FIELDS=NONE
On Tue, 15 Jan 2008 10:25:23 -0600, McKown, John
, DFSORT or CA-Sort.
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Dave Kopischke
Sent: Tuesday, January 15, 2008 12:00 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: DFSORT question MERGE w/SUM FIELDS=NONE
On Tue, 15 Jan 2008 10:25:23 -0600, McKown
John McKown wrote on 01/15/2008 08:25:23 AM:
The manual is unclear on this. First question: Is this supported? I.e.
Yes, SUM FIELDS=NONE is supported for MERGE.
will SORTOUT contain only one of the records with the duplicate key?
Yes.
Second question: Which record will be kept? Random
-Original Message-
From: IBM Mainframe Discussion List
[mailto:[EMAIL PROTECTED] On Behalf Of Frank Yaeger
Sent: Tuesday, January 15, 2008 11:07 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: DFSORT question MERGE w/SUM FIELDS=NONE
[snip]
If NOEQUALS is in effect, it's random
On Tue, 15 Jan 2008 11:05:40 -0600, McKown, John wrote:
Yes, I just didn't really see how EQUALS applies to a MERGE. Possibly
just lact of understanding on my part. I do understand how EQUALS
applies to SORT since SORT is only reading one input file, so which is
first makes sense to me. But MERGE
On Tue, 15 Jan 2008 11:00:01 -0600, Dave Kopischke wrote:
On Tue, 15 Jan 2008 10:25:23 -0600, McKown, John wrote:
The manual is unclear on this. First question: Is this supported? I.e.
will SORTOUT contain only one of the records with the duplicate key?
Second question: Which record will be
(Sorry if this appears twice - the first post seems to be taking forever to
get to the list, so I thought I'd try again.)
John McKown wrote on 01/15/2008 08:25:23 AM:
The manual is unclear on this. First question: Is this supported? I.e.
Yes, SUM FIELDS=NONE is supported for MERGE
On Tue, 15 Jan 2008 11:20:25 -0600, Paul Gilmartin wrote:
Related question:
Does either product support sorting on N keys and eliminating all but
the first record with the first M (N) values identical? E.g. for all
records with identical Names, keep only the one with the most recent
Date.
An
Paul Gilmartin wrote on 01/15/2008 09:20:25 AM:
Related question:
Does either product support sorting on N keys and eliminating all but
the first record with the first M (N) values identical? E.g. for all
records with identical Names, keep only the one with the most recent
Date.
I've
On Tue, 15 Jan 2008 11:27:45 -0600, Dave Kopischke wrote:
An awkward solution would be to sort it in date sequence first, then SORT
dedupe. Multiple passes and not very elegant. But for a small file, who cares
??
If the file is small enough, I do it with an editor.
Would it be better on the
On Tue, 15 Jan 2008 11:20:25 -0600, Paul Gilmartin [EMAIL PROTECTED]
wrote:
Does either product support sorting on N keys and eliminating all but
the first record with the first M (N) values identical? E.g. for all
records with identical Names, keep only the one with the most recent
Date.
Paul Gilmartin wrote on 01/15/2008 09:40:44 AM:
Would it be better on the first pass do sort on name ascending major;
date
descending minor? Then the DEDUPE second pass would be almost trivial.
You can do it in one pass with a DFSORT/ICETOOL job like this:
//S1EXEC PGM=ICETOOL
//TOOLMSG
On Tue, 15 Jan 2008 11:40:44 -0600, Paul Gilmartin wrote:
On Tue, 15 Jan 2008 11:27:45 -0600, Dave Kopischke wrote:
An awkward solution would be to sort it in date sequence first, then SORT
dedupe. Multiple passes and not very elegant. But for a small file, who
cares ??
If the file is small
Dave Kopischke wrote on 01/15/2008 09:57:20 AM:
Will MERGE operate on a single input file, or would it require
SORTIN02 DD DUMMY?
My manual doesn't state a minimum. It just says the maximum is 32 DD's
following the naming pattern SORTINnn. You can skip sequence numbers too
if
you want. My
On Tue, 15 Jan 2008 11:46:02 -0600, Mark Zelden [EMAIL PROTECTED]
wrote:
Will DFSORT operate on Unix files?
Never tried it. I think it would if you got the JCL and sort statements
correct.
This worked (SYNCSORT). But I did have to specify LRECL, BLKSIZE,
and RECFM on the DDs or I got
On Tue, 15 Jan 2008 12:16:53 -0600, Mark Zelden wrote:
Will DFSORT operate on Unix files?
Never tried it. I think it would if you got the JCL and sort statements
correct.
This worked (SYNCSORT). But I did have to specify LRECL, BLKSIZE,
and RECFM on the DDs or I got RC16:
Thanks for the
On Tue, 15 Jan 2008 12:33:01 -0600, Paul Gilmartin [EMAIL PROTECTED]
wrote:
On Tue, 15 Jan 2008 12:16:53 -0600, Mark Zelden wrote:
Will DFSORT operate on Unix files?
Never tried it. I think it would if you got the JCL and sort statements
correct.
This worked (SYNCSORT). But I did have to
Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Mark Zelden
Sent: Tuesday, January 15, 2008 1:17 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: DFSORT question MERGE w/SUM FIELDS=NONE
On Tue, 15 Jan 2008 11:46:02 -0600, Mark Zelden
[EMAIL PROTECTED]
wrote
Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Reda, John
Sent: Tuesday, January 15, 2008 1:42 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: DFSORT question MERGE w/SUM FIELDS=NONE
Mark,
The zFS (or HFS) files appear to the sort as a sub-system data set and
can
On Jan 15, 2008, at 11:16 AM, Dave Kopischke wrote:
On Tue, 15 Jan 2008 11:05:40 -0600, McKown, John wrote:
Yes, I just didn't really see how EQUALS applies to a MERGE. Possibly
just lact of understanding on my part. I do understand how EQUALS
applies to SORT since SORT is only reading one
Thanks,
I should have known that. I feel pretty dumb now. I kept looking in
http://www.marist.edu/htbin/wlvindex?MVS-OEdf/dss manuals because I
thought it should be there.
Thanks again,
Brian
--
For IBM-MAIN subscribe /
snip
I've looked through the DF/dss manuals and I can't figure out how to do
a
backup of the dataset allocations only. With FDR, you can backup a
volume
with a parm of
SELECT ALLDSN,DATA=NONE
which will allow you to create a backup which contains only the
necessary
information to restore
Hi,
I've looked through the DF/dss manuals and I can't figure out how to do a
backup of the dataset allocations only. With FDR, you can backup a volume
with a parm of
SELECT ALLDSN,DATA=NONE
which will allow you to create a backup which contains only the necessary
information to restore
And please remember to quote a little of the original post if you change the
subject.
From: Hunkeler Peter (KIUK 3) [mailto:snip]
Sent: Tue 1/30/2007 11:29 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: How to display JES2 Checkpoint Level (was: -none-)
$d activate
$d activate
netiquette
Would you mind supplying a subject and signing your posts?
/netiquette
Peter Hunkeler
CREDIT SUISSE
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with
Assuming all your group SYS1 users don't also have the OPERATIONS
attribute, there is a separate profile (don't have my manuals handy)
which can be used to just to grant the authority to define aliases in
the master catalog. Perhaps they have access to that.
Crispin Hugo wrote:
I have a
Took me a while to read Dave Yackels paper and the apars, but:
Having said that I still think IBM would have done the majority of users
a favor to ship the new default as .FORNSSI *NONE and provided
appropriate HOLD(ACTION) and updated publications.
The latter is the most important. Even the z
to R6. We expect some
further relief from OA09229 once z/OS R6 is fully implemented on all
systems in the Sysplex but we got considerable immediate relief by a
very small change.
OA08482/UA14743 were already APPLIED on all R4 LPARs so we added
.FORNSSI *NONE to MPFLSTXX and set this active
available
Since all our systems in our sysplexes are z/OS 1.6 and have
OA09229, would this mean anything to us if we added .FORNSSI *NONE
to MPFLSTxx? I'm not clear after reading OA09229 and OA08482
(which added the .FORNSSI support). Or did this just become one
of those best practices to just do
change.
OA08482/UA14743 were already APPLIED on all R4 LPARs so we added
.FORNSSI *NONE to MPFLSTXX and set this active dynamically. We automate
messages on the local system where they are issued so we took the
recommended action and suppressed broadcast to foreign subsystems and I
have not found
On Mon, 17 Oct 2005 14:44:41 -0500, Dave Danner [EMAIL PROTECTED] wrote:
Sam,
After you get Console Restructure with OA09229 installed can you try
turning off .FORNSSI *NONE and reporting what you see? Mr. Fagen can
correct me if I'm wrong, but I thought .FORNSSI was pretty much just a
band
will fix the lion's share of the additional overhead
caused by sending messages around the sysplex (it eliminates the automatic
multicast of all messages), but if you do use the ability to route messages
around the sysplex, OA08482+.FORNSSI *NONE will reduce CPU in the CONSOLE
address space
thanks Mark.
will get right on it.
- ravi.
On Sun, 3 Jul 2005 20:18:54 -0500, Mark Zelden [EMAIL PROTECTED] wrote:
On Sun, 3 Jul 2005 11:51:52 -0500, Mark Zelden [EMAIL PROTECTED]
wrote:
As for Ron's recommendation, you can also implement a DFDSS exit
to the ENQ/RESERVE is only for
: on setting GRSRNL when GRS=NONE
hi Brian.
so, do i take it that when GRS=NONE, both GRSCNF GRSRNL
are ignored ?
does it take an IPL to change GRS to anything other than NONE ?
how then can i take care of the qnames mentioned below ?
thank you.
- ravi
1 - 100 of 104 matches
Mail list logo
