Now, if I can figure out how to do the over punch on this keyboard. :)
Job control language was more like assembler with very, very simple
operations. The problem was that a lot of verby things got put into the
operands.
DD means data definition. The first symbol, SYSIN in this case, is the
On Tue, 29 Jul 2008 11:40:39 PDT "Roman V. Shaposhnik" <[EMAIL PROTECTED]>
wrote:
> [EMAIL PROTECTED] wrote:
> > On the same subject, this quote from Donald E. Knuth, Volume 4
> > fascicle 0 (new addition to The Art of Computer Programming, published
> > in may 2008)---Preface:
> >
> > "Furt
> bundles are implemented by here documents,
> and the end marker for the document must not appear
> in the data
vague recollection (1982), it was something like:
//SYSIN DD *
data
records
go
here
/*
[EMAIL PROTECTED] wrote:
On the same subject, this quote from Donald E. Knuth, Volume 4
fascicle 0 (new addition to The Art of Computer Programming, published
in may 2008)---Preface:
"Furthermore, as in earlier volumes of this serie, I'm
intentionnally concentrating almost entir
Charles Forsyth wrote:
JCL == Java Control Language?
the Job Control Language for System/360
Yeah, I kind of knew that ;-) I was trying to come
up with the best joke I could. If this is not it, I have
no clue what could be funny about JCL ;-)
bundles are implemented by here documents,
>JCL == Java Control Language?
the Job Control Language for System/360
if you follow the link i gave you'll see more.
bundles are implemented by here documents,
and the end marker for the document must not appear
in the data, and IBM JCL syntax (even if it were strictly correct)
was unlikely to
> Job Control Language, I am not sure, but I belive was/is used in batch
> proccessing in the IBM Mainframes.
if invented today, it would be called cobolscript.
- erik
Job Control Language, I am not sure, but I belive was/is used in batch
proccessing in the IBM Mainframes.
Roman V. Shaposhnik escribió:
ron minnich wrote:
more useless crap from memory:
the actual correct usage is
//GO.SYSIN DD *
but of course the * would make things messy.
See this and rea
ron minnich wrote:
more useless crap from memory:
the actual correct usage is
//GO.SYSIN DD *
but of course the * would make things messy.
See this and realize this stuff is still being taught!
http://www.coba.unt.edu/itds/courses/bcis3690/bcis3690.ht
So... for the dense ones (like myself), w
> i think that's right, and that's the interesting case to investigate
provided, of course, that you're interested in the applications that might use
it.
otherwise it will just complicate things to no good effect.
> As far as interfaces go, mmap() is pretty tragic - the underlying
> translation structures can express more interesting things, some of
> which are even worth doing.
> There have even been OSes that let userland apps play with their address
> spaces in far more interesting ways
i think that's r
As far as interfaces go, mmap() is pretty tragic - the underlying
translation structures can express more interesting things, some of
which are even worth doing.
There have even been OSes that let userland apps play with their address
spaces in far more interesting ways - KeyKOS and EROS come to
ron minnich wrote:
On Tue, Jul 29, 2008 at 8:19 AM, erik quanstrom <[EMAIL PROTECTED]> wrote:
you can't make the assumption that a file is local in *ix, either.
in fact, for the last 20 years, every program run on a sunos/solaris
machine has used mmap for the exec.
mmap() is every
On Tue, Jul 29, 2008 at 8:04 AM, Alexander Sychev <[EMAIL PROTECTED]>wrote:
> On Tue, 29 Jul 2008 12:52:14 +0400, Enrico Weigelt <[EMAIL PROTECTED]>
> wrote:
>
> Hi!
>
> an full mmap() is a really nice thing. It can make a lot things
>> easier if you just map the whole file into the process' memo
On Tue, Jul 29, 2008 at 8:19 AM, erik quanstrom <[EMAIL PROTECTED]> wrote:
> you can't make the assumption that a file is local in *ix, either.
>
in fact, for the last 20 years, every program run on a sunos/solaris
machine has used mmap for the exec.
ron
> Yes, it is comfortable.
where's jim when you need him?
> But just think a bit - what will you do in the
> mmap implementation when you had mapped a remote file (in Plan9 you can't
> be sure some file is local or it is really just a file), and the
> connection has just been broken? Surpri
On Tue, 29 Jul 2008 12:52:14 +0400, Enrico Weigelt <[EMAIL PROTECTED]>
wrote:
Hi!
an full mmap() is a really nice thing. It can make a lot things
easier if you just map the whole file into the process' memory and
let the kernel handle the actual IO.
Yes, it is comfortable. But just think a
> It can make a lot things
> easier if you just map the whole file into the process' memory and
> let the kernel handle the actual IO.
the word "superficially" should be in there somewhere.
* Russ Cox <[EMAIL PROTECTED]> wrote:
Hi,
I don't know much of native plan9 (only using plan9port), but IMHO
an full mmap() is a really nice thing. It can make a lot things
easier if you just map the whole file into the process' memory and
let the kernel handle the actual IO.
Some time ago I
19 matches
Mail list logo
