Duaine Hechler wrote:

Since I've been out of the mainframe world for about 13 years, what happened to the mainframe style "full screen" text editors being standard in Linux. Like, XEDIT, KEDIT, ISPF.

They were never ported. OS/2 or VisualAge came with LPEX, which was very good. I think it's in WebSphere now.

And I know about vi, kate, and kwrite BUT these are NOT full screen "text" editors - these are full screen "line" editor. Unlike, XEDIT, where you can move, copy, insert, delete, etc - easily - "blocks" of lines

You can certainly do that in kate too, just as in vi and emacs.

I know versions of these exist, like the "THE" editor. However, why haven't these become the "standard" ? (Even XEDIT, starts basically in character basic "console" mode (no graphics capabilities needed), which could be run in a Linux console session)

Because Unix and Linux already have vi as _the_ standard. No need for another standard.

Having a "system programming" background, I just don't understand why anyone would put up with a "line" editor.

It's not about ones background, it's about habit. I too have worked with MVS, VM and TPF - 20 years ago I would also have argued the case for ISPF and XEDIT, but unless I'm sat behind a 3270 screen or emulator, I don't need them. -- Per Jessen, Zürich (0.0°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Per Jessen said the following on 02/28/2013 02:49 AM:

Duaine Hechler wrote:

...

Since I've been out of the mainframe world for about 13 years, what happened to the mainframe style "full screen" text editors being standard in Linux. Like, XEDIT, KEDIT, ISPF.

They were never ported. OS/2 or VisualAge came with LPEX, which was very good. I think it's in WebSphere now.

...

And I know about vi, kate, and kwrite BUT these are NOT full screen "text" editors - these are full screen "line" editor. Unlike, XEDIT, where you can move, copy, insert, delete, etc - easily - "blocks" of lines

You can certainly do that in kate too, just as in vi and emacs.

Duane, I think you had better clarify what you think the deficiency is, because Per is right. Perhaps its just that you don't know VI etc well enough. There's an excellent book from O'Reilly: http://shop.oreilly.com/product/9780596529833.do and many cheat-sheets. I'm not sure where you gripe comes from since many of the 'mainframe' editors were/are essentially '80-column card image' editors. There was similar in the DEC world where text file types were line oriented - either fixed length (80 column) or zero-delimited. The real distinction that separated UNIX from the mainframe/mini world is that it doesn't have all these ridiculous file types - a file is a continuous array of bytes. Its up to the application to apply semantics.

...

I know versions of these exist, like the "THE" editor. However, why haven't these become the "standard" ? (Even XEDIT, starts basically in character basic "console" mode (no graphics capabilities needed), which could be run in a Linux console session)

Because Unix and Linux already have vi as _the_ standard. No need for another standard.

Its no so much that "vi" is the standard as that, as I say above, UNIX files are array of bytes. There is no OS level file typing. I recall annoyance that when working with DEC/VMS I would enter code with a text editor that the compiler couldn't read. It had many types of text files and the the editor produced one that the compiler couldn't handle. This can't happen with UNIX. Many of the interpreters and compilers under UNIX/Linux treat input as 'array of bytes', the line orientation is just for the convenience of the users reading the code. See, for example, the highly compressed 'obfuscated' contests.

...

Having a "system programming" background, I just don't understand why anyone would put up with a "line" editor.

"Lines" are semantic concepts with UNIX.

From a 'systems programming' POV its the mainframes that are 'line oriented'

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Patrick Shanahan wrote:

* Anton Aylward [02-28-13 10:10]:

...

Per Jessen said the following on 02/28/2013 02:49 AM:

...

Duaine Hechler wrote:

...

Since I've been out of the mainframe world for about 13 years, what happened to the mainframe style "full screen" text editors being standard in Linux. Like, XEDIT, KEDIT, ISPF.

I don't see Hechler's posts, but his problem is more of not looking or not looking in proper places as kedit is provided in kdeutils3-extra:

http://download.opensuse.org/distribution/openSUSE-current/repo/oss/suse/x86... Duaine was looking for kedit, an enhanced xedit. http://en.wikipedia.org/wiki/KEDIT

and xedit is provided: http://download.opensuse.org/distribution/openSUSE-current/repo/oss/suse/x86...

http://en.wikipedia.org/wiki/XEDIT -- Per Jessen, Zürich (3.1°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Anton Aylward wrote:

Per Jessen said the following on 02/28/2013 11:46 AM:

...

Duaine was looking for kedit, an enhanced xedit.

http://en.wikipedia.org/wiki/KEDIT

...

and xedit is provided:

http://download.opensuse.org/distribution/openSUSE-current/repo/oss/suse/x86...

...

http://en.wikipedia.org/wiki/XEDIT

<quote> XEDIT is a visual editor for VM/CMS using block mode IBM 3270 terminals. [1] [2] It is much more line-oriented than modern PC and Unix editors. For example, it supports automatic line numbers, and many of the commands operate on blocks of lines. One of the features is a command line which allows the user to type arbitrary editor commands. Because IBM 3270 terminals do not transmit data to the computer until certain special keys are pressed (such as enter and function keys) XEDIT is less interactive than many PC and Unix editors. For example, continuous spell-checking as the user types is impossible. </quote>

That sounds pretty limited and crippled compare to what's available for Linux.

It isn't. The description above is very poor and/or biased.

VI has line numbering, can work on blocks of lines, and has a command line option. There are also programming plug-ins available.

I wonder why Duaine wants to regress?

He doesn't want to regress, he wants to be effective. He is used to working with those editors and feel that they are way superior to vi et al. I completely understand where he is coming from. I have yet to reach the same level of fluency with vi that I had/have with the ISPF editor or the LPEX ditto. -- Per Jessen, Zürich (1.6°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 02/28/2013 12:04 PM, Per Jessen wrote:

Anton Aylward wrote:

...

Per Jessen said the following on 02/28/2013 11:46 AM:

...

Duaine was looking for kedit, an enhanced xedit.

http://en.wikipedia.org/wiki/KEDIT

...

and xedit is provided:

http://download.opensuse.org/distribution/openSUSE-current/repo/oss/suse/x86... http://en.wikipedia.org/wiki/XEDIT <quote> XEDIT is a visual editor for VM/CMS using block mode IBM 3270 terminals. [1] [2] It is much more line-oriented than modern PC and Unix editors. For example, it supports automatic line numbers, and many of the commands operate on blocks of lines. One of the features is a command line which allows the user to type arbitrary editor commands. Because IBM 3270 terminals do not transmit data to the computer until certain special keys are pressed (such as enter and function keys) XEDIT is less interactive than many PC and Unix editors. For example, continuous spell-checking as the user types is impossible. </quote>

That sounds pretty limited and crippled compare to what's available for Linux. It isn't. The description above is very poor and/or biased.

...

VI has line numbering, can work on blocks of lines, and has a command line option. There are also programming plug-ins available.

I wonder why Duaine wants to regress? He doesn't want to regress, he wants to be effective. He is used to working with those editors and feel that they are way superior to vi et al. I completely understand where he is coming from. I have yet to reach the same level of fluency with vi that I had/have with the ISPF editor or the LPEX ditto. That is correct. In fact so superior, since it interacts with REXX, you can write shell scripts to copy and invoke the editor, for the lack of a better turn, in "script" mode, manipulate files and do what you want with them afterwords.

Now, THIS, is just one of the other capabilities I'm used to - which I can't find in Linux - yet ! Examples: The first file is a basic "shell" file with all changeable parameters setup with and & in front: * $$ JOB JNM=&VOLSER,CLASS=P,DISP=D,USER='DUAINE HECHLER' * $$ LST DISP=H,CLASS=Q * $$ LST LST=06E,DISP=H,CLASS=U,JSEP=0,RBS=0,RBM=0 // JOB &VOLSER PRINT AGE BROKER STATEMENT FROM XEROX TAPE // OPTION LOG,NODUMP // LIBDEF *,SEARCH=PRD2.SYSPROG // TLBL TAPEIN // ASSGN SYS005,&DRIVE // PAUSE **** MOUNT AGE BROKER XEROX TAPE &VOLSER ON DRIVE &DRIVE **** // MTC REW,SYS005 // ASSGN SYS009,06E // EXEC AFPPRINT,SIZE=80K /* /& * $$ EOJ This is the script file that makes global changes, files it and submits it to run: PARSE UPPER ARG VOLSER DRIVE 'ERASE AGE2XRX TEMPJCL A' 'COPY AGE2XRX SHELLJCL * AGE2XRX TEMPJCL A' QUEUE 'TOP' QUEUE 'C /&VOLSER/'VOLSER'/* *' QUEUE 'TOP' QUEUE 'C /&DRIVE/'DRIVE'/* *' QUEUE 'FILE' 'XEDIT AGE2XRX TEMPJCL A' 'EXEC SUBPROD AGE2XRX TEMPJCL A' 'ERASE AGE2XRX TEMPJCL A' EXIT -- Duaine Hechler Piano, Player Piano, Pump Organ - Tuning, Servicing & Rebuilding (314) 838-5587 / dahechler@att.net / www.hechlerpianoandorgan.com Home & Business user of Linux - 13 years -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Duaine Hechler wrote:

Since I've been out of the mainframe world for about 13 years, what happened to the mainframe style "full screen" text editors being standard in Linux. Like, XEDIT, KEDIT, ISPF.

I understand Emacs can be used as an editor. ;-) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Anton Aylward wrote:

Per Jessen said the following on 02/28/2013 01:04 PM:

...

Anton Aylward wrote:

...

[snip,snip, snip]

That sounds pretty limited and crippled compare to what's available for Linux.

It isn't. The description above is very poor and/or biased.

Perhaps you'd care to amplify that -- or even correct the Wikipedia article.

I would if I could. It's difficult - partially because I am biased, mostly because one has to experience both to really understand. And that goes for either side. There is a lot of "religion" in it. There is also the little matter of two completely different environments - a IBM 3270 terminal vs the DEC VT100 (essentially). The former is screen based, the latter is line based.

...

...

VI has line numbering, can work on blocks of lines, and has a command line option. There are also programming plug-ins available.

I wonder why Duaine wants to regress?

He doesn't want to regress, he wants to be effective. He is used to working with those editors and feel that they are way superior to vi et al. I completely understand where he is coming from. I have yet to reach the same level of fluency with vi that I had/have with the ISPF editor or the LPEX ditto.

Ah, that I can understand. My fingers know VI. All these editors that require me to take my hands off the keyboard and fiddle with mouse and menus and icons - and lets face it, icons range from incomprehensible to 'culturally specific'[1].

Very true. I have written a lot of code in ISPF and later xedit. Around the same time I started working with LPEX, which was a big step forward at the time (mid-90s) (syntax highlighting for starters). When I decided to switch to Linux, VI was my weapon of choice, but it took me six-seven years to get really effective with it. I did have a short affair with Eclipse in between, and today when I need to write C, I still pick kate. One funny thing is - the standard IBM line length is 80 chars, which goes all the way back to punchcards. I have not worked with punchcards myself, but IBM JCL is nothing but "screen" punchcards. However, think about how often we limit ourselves to 80 chars - in email, in code, everywhere. If it wasn't for punchcards, we wouldn't have a continuation character. -- Per Jessen, Zürich (0.1°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Duaine Hechler said the following on 02/28/2013 02:32 PM:

AND, I know at least on the mainframe side, you can invoke an option to edit the file in "hex" mode.

RTFM <quote src="man 1 vi"> -b Binary mode. A few options will be set that makes it possible to edit a binary or executable file. </quote> -- Insanity is hereditary. You get it from your kids. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 02/28/2013 02:35 PM, Anton Aylward wrote:

Duaine Hechler said the following on 02/28/2013 02:32 PM:

...

AND, I know at least on the mainframe side, you can invoke an option to edit the file in "hex" mode.

RTFM

<quote src="man 1 vi"> -b Binary mode. A few options will be set that makes it possible to edit a binary or executable file. </quote>

BUT, can you be IN the file and SWITCH back and forth ? -- Duaine Hechler Piano, Player Piano, Pump Organ - Tuning, Servicing & Rebuilding (314) 838-5587 / dahechler@att.net / www.hechlerpianoandorgan.com Home & Business user of Linux - 13 years -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Per Jessen said the following on 02/28/2013 03:15 PM:

Anton Aylward wrote:

...

Per Jessen said the following on 02/28/2013 01:04 PM:

...

Anton Aylward wrote:

...

[snip,snip, snip]

That sounds pretty limited and crippled compare to what's available for Linux.

It isn't. The description above is very poor and/or biased.

Perhaps you'd care to amplify that -- or even correct the Wikipedia article.

I would if I could. It's difficult - partially because I am biased, mostly because one has to experience both to really understand. And that goes for either side. There is a lot of "religion" in it.

"Religion" I can understand.

There is also the little matter of two completely different environments - a IBM 3270 terminal vs the DEC VT100 (essentially). The former is screen based, the latter is line based.

Eh? The KSR-33 was line based but not the VY-100. As far back as 1982 I was using VI on VT100 and clones (made by Wyse or someone) in full screen mode. That's what TERMCAP was for. Thank you Bill Joy.

One funny thing is - the standard IBM line length is 80 chars, which goes all the way back to punchcards. I have not worked with punchcards myself, but IBM JCL is nothing but "screen" punchcards. However, think about how often we limit ourselves to 80 chars - in email, in code, everywhere. If it wasn't for punchcards, we wouldn't have a continuation character.

Yes, but there's a lot about UNIX and the 'Net which doesn't acknowledge line length. Again, as far bask as the 1980s protocols such as NEWS/NNTP the concatenation of the sites the message had passed though produced lines that were of indefinite length, and the code just dealt with that dynamically. That Henry Spenser addressed the input buffer-overflow issue back in the early 1980s, long before the Morris Worm, just shows how lacking our education system is. -- “When dealing with people, remember that you are not dealing with creatures of logic, but creatures of emotions.” —Dale Carnegie -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Duaine Hechler said the following on 02/28/2013 03:54 PM:

On 02/28/2013 02:42 PM, Anton Aylward wrote:

...

[..] So, can you do move lines 827 though 844 to before line 212 in one go? Trivial in VI (and variants).

Well, I'm not that deep in VI and maybe so BUT its not as simple as the other editors !

It would take :827,844m212 I don't see that as complicated. I you wanted to do it graphically, the key strokes might be 827G17dd212Gp That is, Goto line 827 Yank into the transient buffer 17 lines while deleting them Goto like 212 Put the contents of the transient buffer after the current line. I'll grant you there is the issue of 'familiarity'. Everything new looks difficult when you first see it. In practice I may make use of markers so I don't have to count lines, but then again it will depend on context. Those 17 lines might be a paragraph or a region in some kind of syntactic bracketing and I could use that instead. Many UNIX languages use "{" and "}" and its easy enough to say "move the stuff between the bracket the cursor is on and the matching one. This is why I hate HTML and XML! -- "Education must precede motivation." Jim Rohn -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Duaine Hechler said the following on 02/28/2013 04:56 PM:

On 02/28/2013 03:13 PM, Anton Aylward wrote:

...

Duaine Hechler said the following on 02/28/2013 03:54 PM:

...

On 02/28/2013 02:42 PM, Anton Aylward wrote:

...

[..] So, can you do move lines 827 though 844 to before line 212 in one go? Trivial in VI (and variants).

Well, I'm not that deep in VI and maybe so BUT its not as simple as the other editors !

It would take

:827,844m212

I don't see that as complicated.

I you wanted to do it graphically, the key strokes might be

827G17dd212Gp

That is, Goto line 827 Yank into the transient buffer 17 lines while deleting them Goto like 212 Put the contents of the transient buffer after the current line.

Again, its called easy of use. In the other editor, you don't NEED to know the LINE NUMBERS + again, CRYPTIC !!!!!

...

Again, you are missing the point - its called "easy of use" - at the editor command line (while editing the file) - I just say "hex on" or "hex off" - NO "ESC + :" - or - "ctrl" - or any CRYPTIC shit.

Please: don't reply to BOTH me AND the list. Its redundant. As for 'ease of use', that's a matter of opinion. There's nothing cryptic about single letter abbreviations - G for goto, m for move, p for put, d for delete and so forth. The more 'obscure' abbreviations - ctl or meta - are because the users want speed and something like 'go to command line mode, type explicit words' is a but unwieldy for a 'common command'. VI only does that for 'settings'. As for line numbers, I thought you were boasting earlier that those mainframe line editors showed line numbers. VI only does if you explicitly ask it to. As I said, mostly you deal with the syntax. I only illustrated with line numbers since that is independent of language. Normally when I 'shuffle' stuff in VI I use the pattern capability or the marker capability. But you're probably call that 'cryptic'. But its the normal way of working with VI. As I said, so many *NIX languages use "{ ... }" bracketing that its normal to put the cursor on one bracket, VI finds the matching one, and you do an operation on what's in between. You can redefine - per language - what VI thinks of as a 'paragraph' and delimiters, break markers, comment strings and so forth. Line numbers are normally for when you're talking to someone else as in "you have a bug at line 1243" ... that's comment across all architectures! I recall when the PC and MS-DOS proliferated, there were keyboard templates for things like WordPerfect that gave the mnemonics for the function keys. GEE WOW! UNIX grew up with a terminal independent environment, not like your dedicated IBM terminals. The reason for TERMCAP et al was that the programmers didn't know what terminal applicability a program could expect. So we relied on things like ctl key sequences that could be types on ANY terminal. That you now have a 105-key PC keyboard and 9-button mouse with 3-d scroll-wheel is fortunate. But we didn't have any of that back when it was a cheap terminal that incorrectly and incompletely emulated a VT-100. It's nice that modern VI will allow you to re-define just about any sequence you want. -- This isn't life in the fast lane, it's life in the oncoming traffic. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Anton Aylward wrote:

It's nice that modern VI will allow you to re-define just about any sequence you want.

I'm surprised noone has bothered pointing out how OT this all is :-) Anyway, Unix runs in a multitude of environments, MVS and VM don't - that is a very important difference too. -- Per Jessen, Zürich (1.7°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Anton Aylward wrote:

Per Jessen said the following on 02/28/2013 03:15 PM:

...

There is also the little matter of two completely different environments - a IBM 3270 terminal vs the DEC VT100 (essentially). The former is screen based, the latter is line based.

Eh? The KSR-33 was line based but not the VY-100. As far back as 1982 I was using VI on VT100 and clones (made by Wyse or someone) in full screen mode. That's what TERMCAP was for. Thank you Bill Joy.

Not the interface, the technology. Everything you send to a VT-100 is line base, one long string, optionally with ANSI control characters. A 3270 is more like a directly addressable full screen. Well, I guess whatever comes down the line is a string too, but that's what a 3270 looks like to a programmer.

...

One funny thing is - the standard IBM line length is 80 chars, which goes all the way back to punchcards. I have not worked with punchcards myself, but IBM JCL is nothing but "screen" punchcards. However, think about how often we limit ourselves to 80 chars - in email, in code, everywhere. If it wasn't for punchcards, we wouldn't have a continuation character.

Yes, but there's a lot about UNIX and the 'Net which doesn't acknowledge line length.

Definitely.

Again, as far bask as the 1980s protocols such as NEWS/NNTP the concatenation of the sites the message had passed though produced lines that were of indefinite length,

Hmm, don't they follow email standards? I'm sure USENET is where we first saw base64 encoding folded into neat lines of 76 bytes. Even the linux kernel likes the 80 character limit: "The limit on the length of lines is 80 columns and this is a strongly preferred limit."

From http://www.kernel.org/doc/Documentation/CodingStyle

Anyway, we're way OT. -- Per Jessen, Zürich (2.7°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Per Jessen said the following on 03/01/2013 05:27 AM:

Last I worked with ISPF edit (late 80s) I remember installing some copy and paste macros too, they made a lot of stuff much easier.

macro capability is good. Every serious editor should have that capability. Confession: I've rather overloaded the :map on my VI -- Me...a skeptic? I trust you can prove that. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Per Jessen said the following on 03/01/2013 05:57 AM:

Anton Aylward wrote:

...

Per Jessen said the following on 02/28/2013 03:15 PM:

...

There is also the little matter of two completely different environments - a IBM 3270 terminal vs the DEC VT100 (essentially). The former is screen based, the latter is line based.

Eh? The KSR-33 was line based but not the VY-100. As far back as 1982 I was using VI on VT100 and clones (made by Wyse or someone) in full screen mode. That's what TERMCAP was for. Thank you Bill Joy.

Not the interface, the technology. Everything you send to a VT-100 is line base, one long string, optionally with ANSI control characters. A 3270 is more like a directly addressable full screen. Well, I guess whatever comes down the line is a string too, but that's what a 3270 looks like to a programmer.

And its just the same with VI and other applications that used the ncurses package and the like (ncurses was 'extracted' from the original VI's mechanisms). They maintain a internal screen logical image. IIR Bill Joy's VI kept this as a linked list. I once had to work on that code and boy was it crufty! One man's really optimized work and almost unintelligible to mere mortals. the code-base for VIM is so much nicer. So, to the programmer working with ncurses the programming model was a directly addressable full screen. You updated it and then did a 'sync' -- "refresh()', and the algorithms worked out the best/optimal/minimal stuff to send to the terminal. http://frank.harvard.edu/~coldwell/ncurses/ncurses-intro.html#updating And there in is the difference. TERMCAP tried to support cursor addressing and such things as as region (not just single line) updates. Some terminals could update a region in the middle of the screen: specify a bounding box and fill it thusly. So using ncurses was efficient on bandwidth (great over a slow modem). The programming reality was that there were higher level layers of code that made the manipulation of such easier, all the way up to 'layers' which implemented a text-based windows system. (e.g. http://osr507doc.sco.com/en/man/html.M/layers.M.html, http://osr507doc.sco.com/en/man/html.C/layers.C.html) You might also find the referred to as 'panels' http://frank.harvard.edu/~coldwell/ncurses/ncurses-intro.html#panels Of course this got rapidly replaced when the IBM PC came out and made cheap graphics and eventually GEM and MS-Windows available. I still have the SVR4 and USG manuals .. moment. Here we are: AT&T System V Interface Definition Volume 2, Part VI Terminal Interface Extension Definition. P426 Curses - CRT screen handling and optimization package. ISBN: 0-932764-10-X

...

...

One funny thing is - the standard IBM line length is 80 chars, which goes all the way back to punchcards. I have not worked with punchcards myself, but IBM JCL is nothing but "screen" punchcards.

I had to for a very short time. I hated it and soon found a PDP-11 running RSTS that supported RJE. That PDP-11 was then knobbled by some post-grads to run UNIX version 5, and I didn't want to let go, so they took me along as test case for their work on compiler development and I got to play with the new languages they were dreaming up. And UNIX. Eventually I did system and kernel hacking on V6 and V7, then on System III and System V commercially.

...

...

However, think about how often we limit ourselves to 80 chars - in email, in code, everywhere. If it wasn't for punchcards, we wouldn't have a continuation character.

Yes, but there's a lot about UNIX and the 'Net which doesn't acknowledge line length.

Definitely.

Strictly speaking email doesn’t limit itself to 80 columns. Much of the mail I get seems to have been composed with long lines - one line per paragraph, and its up to the display to do the soft line wrap. So if I shrink or grow the width of the window the individual lines alter in length. Well, maybe. I've set Thunderbird to wrap at 79 no matter what, but its easy to see this behavior if you use a word processor such as OpenOffice/LibreOfice. Oh, right, that's cos its HTML mail. EVIL!

...

Again, as far bask as the 1980s protocols such as NEWS/NNTP the concatenation of the sites the message had passed though produced lines that were of indefinite length,

Hmm, don't they follow email standards? I'm sure USENET is where we first saw base64 encoding folded into neat lines of 76 bytes.

I'm talking about the HEADERS not the body. See http://www.tldp.org/LDP/nag/node258.html <quote> A site may find out about all other sites the article has already traversed by looking at the Path: header field. This header contains a list of all systems the article has been forwarded by in bang path notation. </quote> I'm not talking about 'source based routing' as with UUCP, though that might apply a well. No, I'm talking about Henry's code in C-News that read lines of indefinite length with NO BUFFER OVERFLOW.

Even the linux kernel likes the 80 character limit:

"The limit on the length of lines is 80 columns and this is a strongly preferred limit."

...

From http://www.kernel.org/doc/Documentation/CodingStyle

That's about readability of the sources. The kernel itself has no such requirement.

Anyway, we're way OT.

Getting there .... -- In view of the stupidity of the majority of the people, a widely held opinion is more likely to be foolish than sensible. --Bertrand Russell, Marriage and Morals -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Anton Aylward wrote:

Per Jessen said the following on 03/01/2013 04:33 AM:

...

Anton Aylward wrote:

...

It's nice that modern VI will allow you to re-define just about any sequence you want.

I'm surprised noone has bothered pointing out how OT this all is :-)

Anyway, Unix runs in a multitude of environments, MVS and VM don't - that is a very important difference too.

I was at a Novell presentation a while back when they were pushing Suse - SLED and SLES - and there was a presentation from IBM about how they were running Suse as their virtual Linux on a mini-mainframe. This box about the size of a bar fridge could support over 4,000 virtual instances of Suse Linux.

Yeah, Linux/390 - it's pretty cool stuff. I did some work on porting SAPDB to it some years back.

I WANT ONE!

Look up the Hercules project, you can start your training there. You might even get to run some old ISPF editor :-) -- Per Jessen, Zürich (3.1°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 03/01/2013 02:43 PM, Greg Freemyer wrote:

...

Even the linux kernel likes the 80 character limit:

"The limit on the length of lines is 80 columns and this is a strongly preferred limit."

...

From http://www.kernel.org/doc/Documentation/CodingStyle

Anyway, we're way OT.

That is out of date. Kernel coders dropped that a couple years ago.

but it's still used in other projects, e.g. in coreutils it's even enforced by the 'make syntax-check' rule "sc_long_lines": http://git.sv.gnu.org/cgit/coreutils.git/tree/cfg.mk#n223 Have a nice day, Berny -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org