On 2013-09-30 03:30, Sampsa Laine wrote:
On 30 Sep 2013, at 03:27, Johnny Billquist <bqt at softjar.se> wrote:
No.
Johnny
Different sense of humour I guess, and I AM bored out of mind here (in Egypt right now, can't even scuba dive due to shoulder injury, curfew at night, everyones left town more or less)..
I'm in village with a few hundred beduins + their camels and goats it feels like.
Decent 3G coverage though.
Yeah. I probably don't have a great sense of humor. I'm more of the hack-in-the-kernel type of guy. That is what I find really enjoyable...
Make everything run and function smooth, tidy and efficient. I also have a very strict ordering and system to my records, my books and god knows what else... And I like straight angles when I draw on a paper. :-)
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
>Mark Wickens wrote:
If I wanted to go all bling like some of you lot and have a fancy welcome message, does anyone know of a VT escape code screen editor which will allow me to design a welcome message to end all welcome messages?
If by a VT escape code screen editor, you mean
a program which will display the message exactly
as the final display and convert the text to a file
when finished, I have not know of such an
application for any operating system I have used.
The second option is an ordinary text editor with
ONE special provision - the <ESC> character is
displayed as a standard display character. Both of
the editors that I use under RT-11, KED and TECO,
convert the <ESC> character to a "$" for display
purposes. You then are responsible for building
the rest of the text based on the escape sequences
detailed in the programmer's manual for the VT
which you are using. Under RT-11, the user then
issues the command to TYPE the file in order to
test the results.
The third option is to write an actual program to
display the text. If the welcome message is to be
part of the application, that may be the best option.
The reason it may be the best is that graphics
characters may be difficult to handle by the second
option.
If you can use some additional help, ask some
more questions.
Jerome Fine
On 30 Sep 2013, at 03:27, Johnny Billquist <bqt at softjar.se> wrote:
No.
Johnny
Different sense of humour I guess, and I AM bored out of mind here (in Egypt right now, can't even scuba dive due to shoulder injury, curfew at night, everyones left town more or less)..
I'm in village with a few hundred beduins + their camels and goats it feels like.
Decent 3G coverage though.
Sampsa
On 2013-09-30 03:23, Sampsa Laine wrote:
Apart from the SMG$ library, he might want to play with FMS. But I agree with you that I personally don't find it amusing at all.
Python luckily has bindings for SMG$ - and come on, a VMS shell that looks like an IBM Mainframe? That's kinda funny, no?
No.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
Apart from the SMG$ library, he might want to play with FMS. But I agree with you that I personally don't find it amusing at all.
Python luckily has bindings for SMG$ - and come on, a VMS shell that looks like an IBM Mainframe? That's kinda funny, no?
sampsa
It's not amuzing; nor are the myriad absurd DCL menuing interfaces I've
seen implemented at all too many sites over the years.
Well I guess you could use it for something practical as well, but the
default panels I will supply will be as close to IBM ISPF as possible.
On 2013-09-30 01:52, Sampsa Laine wrote:
On 29 Sep 2013, at 23:15, Cory Smelosky <b4 at gewt.net> wrote:
THe OSI model is pretty much a load of BS. 3 layers can be condensed to about 1 and one of them just doesn't exist.
I never understood what the hell the session layer was for anyway - I figure anything above layer 3 (transport) should be handled by apps, not by 4 layers of network stack.
Well, transport is supposed to be layer 4, but anyway... The whole OSI model *is* BS. If I remember right back when they were creating it (by committee of course), the US delegates wanted 6 levels, and Europeans wanted 8, so they compromised on 7.
And of course, they didn't base it on anything working. It's a paper product that noone ever really implemented. DECnet Phase V is as close as anyone ever got, if I remember right. And phase V wasn't exactly a success. But it sure took time and resources to implement.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On 2013-09-29 23:53, Brian Schenkenberger, VAXman- wrote:
Sampsa Laine <sampsa at mac.com> writes:
This is a little bit unfair for the blue guys :)
=20
ISPF is far more than a set of screens to invoke TSO commands. The =
panels (that's how ISPF screens are called) are just a part of the whole =
thing. ISPF integrates with TSO, so we are talking about:
=20
- The TSO command language (CLIST language) and also the REXX =
language.
- The panel facility.
- The skeleton facility.
=20
It is quite easy to "simulate" the ISPF panels (you just need DCL to =
do it, I did it when I worked with DEC machines in a mostly IBM-centric =
company), but that would be just the user interface. The APIs provided =
with ISPF are way beyond that...
I was planning on developing a simple format for defining the panels, =
mapping the options to DCL and any params / switches they need. I am =
aware that ISPF can be used for way more than the basic IDE / sysop =
functions that it comes with by default, don't some ISVs actually build =
their software using ISPF panels as the interface?
I just thought a IBM mainframe lookalike interface to VMS would be =
amusing if nothing else.
It's not amuzing; nor are the myriad absurd DCL menuing interfaces I've
seen implemented at all too many sites over the years.
If you really want to implement a menu interface on VMS, have a look-see
into the SMG$ library. Roll-your-own ESCAPE sequences called out in DCL
command procedures leads to problems with terminal compatibility, as well
as horrors when trying to debug[*] and maintain it.
Apart from the SMG$ library, he might want to play with FMS. But I agree with you that I personally don't find it amusing at all.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On 28 Sep 2013, at 11:30, Johnny Billquist <bqt at softjar.se> wrote:
Never seen any of that either. There was a block mode version of the VT100 as well, if I remember right. Maybe compatible? Although I have not seen the documentation for that one either.
This looks kinda nifty too: http://en.wikipedia.org/wiki/HP_2640
I wonder if there are any HP1000/3000
On 28 Sep 2013, at 11:36, Johnny Billquist <bqt at softjar.se> wrote:
On 2013-09-28 11:30, Sampsa Laine wrote:
Yeah I was thinking of typing up some Arabic documents in say EDIT and using TYPE to view them - but Terminal.app doesn't seem to pass the Arabic letters across correctly.
I think you are a little confused.
I probably didn't express myself clearly enough :)
"Arabic letters" as such don't pass through anywhere. We're talking computers here. Everything is ones and zeroes.
Except Terminal.app only accepts Latin letters as input, rejects Arabic. Not a VMS issue.
It's just a case of how you choose to interpret those ones and zeroes at each end. Are you saying that Terminal.app (a program I avoid by the way, since the VT100 emulation is buggy)
I've not run into any major issues with
