On Thu, 17 Jul 2014 13:08:34 +0800 Timothy Sipples sipp...@sg.ibm.com wrote:
:In my experience most customers migrating from PL/I for MVS to Enterprise
:PL/I do not recompile every program in their inventory all at once (option
:#1), though of course that's certainly possible and admirable. They
Contact Service Express www.seiservice.com 800.940.5585
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
On Wed, 16 Jul 2014 03:09:41 -0500, Shane ibm-m...@tpg.com.au wrote:
H ...
http://www.bbc.com/news/technology-28321897
Shane ...
Do they release this kind of news the day before IBM's earnings report is due
on purpose?
Dana
Again, Mr. Dissen is riding his hobby horse: 'ivory tower' approaches
are bad, and 'real-world' approaches are good; and he has constructed
a straw man in order to do so.
I nowhere recommended that the entire inventory [of PL/I programs] be
recompiled at the same time. I did strongly deprecate
These things are already documented in PrOp text. There can be no
real objection to Yet Another Instructions Table, but we already have
a number of these tables that rehearse/rehash information available in
the discussions of individual instructions.
The PrOP is already bloated, all but
5 cents is what I think I remember was the going price for an apple at an apple
cart on the street during the Great Depression era in the USA.
However, I think cigars were 5 cents then, too. So maybe one really good apple
should sell for $8 US.
Bill Fairchild
- Original Message -
Did you send in an RCF?
Robert A. Rosenberg wrote:
In my opinion the table is defective since E3** should be flagged to
note that the ** is not offset 1 but actually offset 5 in the
instruction. Any instruction where the listed opcode is NOT the first
nibbles of the instruction should be
Not literally 5 cents but '5¢' was what appeared on those signs. At
that time a loaf of Wonder® Bread or a six-oz bottle of Coca-Cola®
also cost 5¢.
John Gilmore, Ashland, MA 01721 - USA
--
For IBM-MAIN subscribe / signoff /
On Wed, 16 Jul 2014 23:55:06 -0400, Robert A. Rosenberg wrote:
In my opinion the table is defective since E3** should be flagged to
note that the ** is not offset 1 but actually offset 5 in the
instruction. Any instruction where the listed opcode is NOT the first
nibbles of the instruction should
I've been wading thru the documentation (DFSMS Using Data Sets), etc...
trying to figure out why the DCBBLKSI field of my DCB is not
being filled in for a RECFM=U data set for INPUT. (Non-LBI)
In particular, I want to allocate a buffer of sufficient size to hold
any block
we might read for a
On Thu, 17 Jul 2014 16:04:20 -0400, Thomas David Rivers wrote:
I put zeros into the DCB before the OPEN; then I do the OPEN... expecting
the DCB to have the DCBBLKSI field set to the block size...
But - it remains zero.
The JCL (well, an SVC 99 actually) doesn't specify a BLKSIZE for the file.
On Thu, 17 Jul 2014 16:04:20 -0400, Thomas David Rivers wrote:
I've been wading thru the documentation (DFSMS Using Data Sets), etc...
trying to figure out why the DCBBLKSI field of my DCB is not
being filled in for a RECFM=U data set for INPUT. (Non-LBI)
The JCL reference has this:
quote
On Thu, 17 Jul 2014 16:04:20 -0400, Thomas David Rivers wrote:
Does anyone know why the DCBBLKSI field would not be filled in ?
Was the OPEN successful?
--
Tom Marchant
--
For IBM-MAIN subscribe / signoff / archive access
On Thu, 17 Jul 2014 15:39:43 -0500, Tom Marchant wrote:
In particular, I want to allocate a buffer of sufficient size to hold
any block
we might read for a pre-existing RECFM=U data set.
Why not use 32760?
Don't some devices support larger blocks nowadays?
(But is that returned in DCBBLKSI?)
What IBM pub will map out the RB structure.
Thanks
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Found it. In volume 5 of data areas
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of John Norgauer
Sent: Thursday, July 17, 2014 2:04 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: mapping SVRB and PRB
What IBM pub will map out the RB
Thomas David Rivers wrote:
I've been wading thru the documentation (DFSMS Using Data Sets), etc...
trying to figure out why the DCBBLKSI field of my DCB is not
being filled in for a RECFM=U data set for INPUT. (Non-LBI)
In particular, I want to allocate a buffer of sufficient size to hold
On Thu, 17 Jul 2014 17:24:30 -0400, Thomas David Rivers wrote:
- After the OPEN has finished, the DCBBLKSI field remains 0.
Do you have a DCBE?
- In this case, we _could_ use 32760 for the size of the read buffer
to allocate.. that seems rather large... and, does LBI mean that
Since 'BIRR.' is already your working directory, what happens if you use
RETR D196.T145616.LISTING
instead of
RETR 'BIRR.D196.T145616.LISTING'
Regards,
--Roger
On Wed, Jul 16, 2014 at 11:51 AM, Christian Birr
christian.b...@birrconsulting.de wrote:
Miklos,
I can't tell you, the FTP process
I agree with most of that, but: on a site which uses such an old PL/1
compiler
version there is not much life on this platform. The platform seems
already to
be almost dead there (if not PL/1 is only, say, 5 % of the inventory, and
the rest is, for example, COBOL ... then staying with such old
Tom Marchant wrote:
On Thu, 17 Jul 2014 17:24:30 -0400, Thomas David Rivers wrote:
- After the OPEN has finished, the DCBBLKSI field remains 0.
Do you have a DCBE?
No DCBE - just an ol' below-the-line DCB.
- In this case, we _could_ use 32760 for the size of the read
On Thu, 17 Jul 2014 21:11:52 -0400, Thomas David Rivers wrote:
But - what's the tracklen of a BSAM UNIX file?
Given that you posted a DSLIST INFO showing UNIT=3390, I'm
calling that question hypothetical. But OPEN's not filling in DCBBLKSI
remains a mystery.
So, does this mean you can use
On Thu, 17 Jul 2014 21:11:52 -0400, Thomas David Rivers wrote:
pouring thru the documentation, I could only find sentences that indicate the
DCBBLKSI
is only filled in by OPEN for F/FB/V/VB files. This leads me to wonder,
perhaps it
simply isn't filled in for RECFM=U? (Which is what appears
Bernd:
My personal opinion is that LE did the job of killing off compilers
(PL1 COBOL etc).
LE tied the level of the OS to the compiler.
Ed
On Jul 17, 2014, at 6:51 PM, Bernd Oppolzer wrote:
I agree with most of that, but: on a site which uses such an old PL/
1 compiler
version there is
RECFM=U stands for undefined. As someone else already pointed out, every block
can be of different length, no matter what block size is set. The block size
field in the DCB is used to communicate the current block's length between the
program and the access method. I can imagine this to be the
Bernd Oppolzer writes:
...BTW, at the site where I am working, we are staying
with EP PL/1 3.9 for similar reasons since three or more
years now, I think.
Enterprise PL/I Version 3.9 is still supported and will be until April 30,
2015. It'd be a very good idea to start heading to Version 4.4 now,
26 matches
Mail list logo
