On 12/10/2013 5:36 AM, Graham Harris wrote:
There are no special SMF records for java stats per se. I must say, that
the amount of CPU indicated in your table, is somewhat surprising, as java
simply isnt that 'cheap'. Especially, when considering the elapsed
timejava very rarely sits
In a18c3cda-9db5-41e9-9df6-bcead854e...@aim.com, on 10/10/2013
at 07:57 PM, Paul Gilmartin paulgboul...@aim.com said:
Bits is bits. A UNIX file is simply a flat linear file;
A PDS member is not a flat linear file.
Why couldn't the same information be stored in a PDS?
Because a PDS member
We need some distinctions here.
A PDS member containing a source program or an object module is not
different internally from a 'flat file' containing the same card
images. Such a member can be read by BSAM or QSAM
A PDS member containing a load module has a very different, hybrid
makeup
On 10/12/2013 5:42 AM, John Gilmore wrote:
A PDSE member containing a program object has a very different, and
very sketchily documented, mixed internal structure. Moreover, the
loading of some of its text elements may be deferred until they are
required|requested.
This is one of the big
Is there any reason that a PDS, RECFM=U or Vxx with half-track or 4K or
whatever records or blocks, could not store *exactly* the same stream of
bytes as a UNIX file, and with no reliance on any special directory
structure?
I am too lazy to do the experiment, but I'll bet you could take a COBOL 5
W dniu 2013-10-12 17:40, Charles Mills pisze:
Is there any reason that a PDS, RECFM=U or Vxx with half-track or 4K or
whatever records or blocks, could not store *exactly* the same stream of
bytes as a UNIX file, and with no reliance on any special directory
structure?
I am too lazy to do the
PDSE is over 20 years old!
What makes it 'special' after all this time?
Welcome to the 1990-s!
-
Ted MacNEIL
eamacn...@yahoo.ca
Twitter: @TedMacNEIL
-Original Message-
From: Charles Mills charl...@mcn.org
Sender: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU
Date:
On Sat, 12 Oct 2013 08:42:02 -0400, John Gilmore wrote:
A PDSE member containing a program object has a very different, and
very sketchily documented, mixed internal structure. Moreover, the
loading of some of its text elements may be deferred until they are
required|requested.
sketchily
How is it connecting to DB2? Type 4 or RRSAF?
On Oct 8, 2013 8:00 AM, David Crayford dcrayf...@gmail.com wrote:
I'm running a test case for one of our products that's currently in
development and I can't figure out how to account for the total CPU time
for a Java program that executes a DB2
Paul,
While I am NOT a fan of PDSE's, I believe that there are entries in
the PDSE directory (ie entries GT 9 bytes) that cannot be contained
in a normal PDS directory. Or there are items that cannot be
contained in a PDS directory. Such items as an entry point in c++ (or
any other
Right, of course.
But the point is that that magic could just as easily be contained in the
body of any file, as it is in a UNIX file, even if that file were a PDS
member (or, for that matter, a non-PDS QSAM/BSAM dataset).
Okay, the next pointless experiment I am too lazy to do: You could make
I have just read Paul's most recent post. I find that I do not agree
with even one of his contentions.
Worse, I discover that I lack the patience to attempt another detailed
exposition of what I take to be his misapprehensions. Exit jg.
On 10/12/2013 12:39 PM, Ted MacNEIL wrote:
PDSE is over 20 years old!
What makes it 'special' after all this time?
Welcome to the 1990-s!
People are funny that way. Note that a bridge built in the fourteenth
century is still called Newbridge:
The discussion so far has been about SYSTEM-Managed Duplexing. What hasn't
been discussed is USER-Managed Duplexing. The latter (DB2 Group Buffer
Pools only so POSSIBLY not relevant to the Original Poster) generally sees
far fewer requests to the Secondary structure.
Which is why customers are
I omitted in my last post to answer the question
Is there an IBM utility that is smart enough to make a UNIX executable
into a program object in a PDSE?
There is|are. The z/OS UNIX System Services commands cp and mv and
the TSO commands OGET and OPUT can do the necessary conversions in
both
On Sat, 12 Oct 2013 14:26:19 -0400, John Gilmore wrote:
There is|are. The z/OS UNIX System Services commands cp and mv and
the TSO commands OGET and OPUT can do the necessary conversions in
both directions.
And, of course Binder, which I suspect all the others (along with IEBCOPY)
invoke
I said 'his contentions'. I did not suggest and do not think that
your example was inaccurate.
I could produce abundant counter examples, and we should then be
reduced to arguing about their essential and inessential features. A
slip path does not establish a generality, although it does in
W dniu 2013-10-12 18:39, Ted MacNEIL pisze:
PDSE is over 20 years old!
What makes it 'special' after all this time?
Welcome to the 1990-s!
Special does not mean new or innovative. PDSE is 20+ yo, but still
under construction, and still undocumented (I mean free documentation).
My whisky is
Note: When you use the DE parameter with the LOAD macro, DE specifies
the address of a list that was created by a BLDL macro.
Thanks for pointing that out. One might argue that it is correct, as what
the BLDL macro creates is the list based on the header that the invoker
of the BLDL macro
On 10/12/2013 9:07 PM, Peter Relson wrote:
15. Therefore, do not issue an ATTACH or a DETACH macro between issuances
of the BLDL and the LOAD macros.
Actually, I have no clue what the last sentence really means. Certainly it
is perfectly find to attach a new task and/or detach an old task
20 matches
Mail list logo
