Fullscreen support for VM/370 Sixpack

[Robert O'Hara]

I thought I'd continue the discussion with a new subject since KICKS has other issues besides fullscreen support. After reading the long discussion, let me try and summarize:

1. Many people would love to see fullscreen 3270 support. This would allow a fullscreen editor to be created. It would allow other programs that rely on fullscreen interaction to be ported to VM/370.

2. Duplicating the support for this that IBM created is a LOT of work: several large modules in CP. As Dave Wade has pointed out, the comparatively simple changes to get highlighting in EDIT to work were themselves quite difficult. I am somewhat familiar with the problem, and I agree with Dave, this is hard code to write and to get right. For us hobbyists I think it is not practical.

3. There are alternative solutions possible. Each has strengths and weaknesses, which we might explore.

Perhaps we can divide the solution space up for clearer discussion. Here is my take at possible solutions. Perhaps there are others out there!

Type 1: Dial support

If we have a CMS application that does 3270 I/O to an attached 3270 instead of the console, then many problems go away. There is no issue switching between "line mode" managed by CP and "fullscreen mode" managed by the application, because they are running on separate terminals.

Pro: Not too hard to implement, I think. If you have source code for 3270 programs, not much modification required, I suspect. It might even be possible to bury this code inside DIAG 58 and thus make it highly compatible to what IBM has done.

Con: Not sure about the last point above, investigation needed. Thus this may not be compatible with VM/SP or z/VM...

Type 2: Write a better terminal emulator

Mike Noel proposed this yesterday: embed 3270 data streams in the linemode console data stream, and have a modfied terminal emulator that does the right thing.

Pro: Similar to type 1 above.

Con: Similar to type 1, above.

Type 3: Forget the 3270

Paul Edwards has pointed out that it is straightforward to download the file you want to edit to an editor running on your local OS (Windows, Linux, etc). I work this way every day: My VMConsole program supports automatic download of CMS files to a Windows editor, and when I save it on Windows it is automatically uploaded to CMS. Any modern PC editor will run rings around a 3270-based editor, of course.

Also, VMConsole today lets you pop-up a Windows dialog box from CMS. This clearly could be extended to support forms-based input.

Pro: Easy to implement, as it is already working.

Con: Not really 3270 support at all.


Well, those are my thoughts.

Bob O'Hara

[kerravon86]

Post by Robert O'Hara
1. Many people would love to see fullscreen 3270 support.

I think at this point we need some "user requirements".

Hello <insert name of person who wants fullscreen
3270>. We are doing some market research, and would
appreciate if you could answer some questions.

1. Why do you want fullscreen 3270? Please list
specific applications if possible.

2. Are you happy to use a dial-in terminal or do
you really want the console?

3. Are you happy to tie yourself down to a single
open-source 3270 emulator, e.g. c3270, or do you
wish to bring your own?

4. Are you happy to run a modified/hacked version
of Hercules as part of the solution?

5. Are you willing to break some of the virtualness
of VM in order to get your application to work? E.g.
if you were required to name an I/O device that
was to not be virtualized.

6. Are you concerned about security, ie a
(deliberate) rogue CMS application (that you
presumably downloaded from a porn site, or
was perhaps planted on your computer by one of
these women:
http://coldfury.com/?p=26032
) being able to trash minidisks that it really
shouldn't be able to access?

7. Are you a large corporation running a production
system, or a hobbyist?

8. If you are a large corporation, what is your
budget for the provision of a solution?

9. If you are a hobbyist, do you have the skills,
time, desire to write part of the solution?

10. If you are a hobbyist, but lacking the skills,
time or desire to write it yourself, will you
accept practically anything that someone else
will provide, or are you a third world snob
(remember all those poor starving Chinese your
parents told you about - who only had half a
bowl of rice to eat per day - and thus you
should be so grateful for the boiled peas and
boiled potatos and boiled meat - top of the line
English cuisine as we all know - turns out that
there was quite a dollop of poetic licence in
those claims, which you will find out if you
actually meet some of those Chinese and try to
introduce them to the (above-mentioned) finest
of English cuisine)?

11. Are you or any members of your family employees
of IBM who are participating in this group purely
to hamper usable solutions that may compete with
IBM products that may or may not have been publicly
released at the time of this questionairre?

12. Have you or any members of your mosque or
extended family (ie first cousins, second
cousins and third cousins - whatever that
actually means - over here only the Tasmanians
are sufficiently inbred that they even know
what the terms mean) been convicted of a terrorist
offence anywhere in the world. (Hey, even though
the terrorists aren't dumb enough to fall for
that one on the immigration forms they hand out
on aeroplanes, doesn't mean that they won't slip
up at "Simon says" in a Herc group).

13. Sign here (e.g. Gemini)


Thankyou for participating in this survey. Your
opinion is important to us (actually, this time
it really is), and rest assured that your
response will remain confidential (as confidential
as a forum that is relayed to nabble and has the
last decade of archives searchable via index and
exported to google - which some would argue makes
it pointless to make the original archives not
publicly readable in the first place - but who am
I to argue with the powers that be - can be, anyway).

Disclaimer - the publishing of this survey does
not explicitly or implicitly imply (regardless
of whether that is or isn't even valid English)
that any member of this forum, nor their children
and grandchildren, are committing themselves to
following or implementing the results of this survey.

Post by Robert O'Hara
Perhaps we can divide the solution space up for
clearer discussion.

I would have divided it into two broader categories
myself.

1. Solutions proposed by people who are actually
familiar with VM.

2. Non-solutions proposed by zombies from the
MVS side, who if I had my way would be banned
from this VM group.

Post by Robert O'Hara
It might even be possible to bury this code inside
DIAG 58 and thus make it highly compatible to what
IBM has done.
Con: Not sure about the last point above, investigation
needed. Thus this may not be compatible with VM/SP or z/VM...

Surely someone here knows the answer to that one
way or the other? Or is that what the CPWATCH
investigation is all about?

Post by Robert O'Hara
a modfied terminal emulator that does the right thing.

For some values of "the right thing".

Post by Robert O'Hara
Any modern PC editor will run rings around a
3270-based editor, of course.

Right, you've got to be pretty weird to want to use
a 3270 editor. What will they be doing next?
Running 25 year old operating systems? Ooops. :-)

Post by Robert O'Hara
Also, VMConsole today lets you pop-up a Windows
dialog box from CMS. This clearly could be extended
to support forms-based input.

Crikey. And this could be put into DIAG 58 too?

I guess we have to defer to user requirements
at this point though. At some point you have
to just ask why people aren't running normal
Windows programs under Windows.

For me, I like my actual executables to be
able to run on real VM, real hardware. So
Windows is just a means to be able to target
that. Even if the application in reality only
ever runs on Windows.

Post by Robert O'Hara
Well, those are my thoughts.

Thanks for trying to summarize that, although
I think more options should be on the table
(modifying Hercules in a couple of different
ways, modifying CP in a couple of different
ways).

BFN. Paul.

[Rocky]

Bob,

Your summary is pretty much right on as far as I can see.
Actually there hasn't been much discussion of 3270 emulator but I think that
is unreal as you can't be emulator dependent and then hardware dependent.

On the positive side:

I have an old application that I wrote back in early 80's that supported
Multiple terminals in full screen from dial mode as well as support for lots
of other goodies.

Pseudo multi tasking, storage control for getmains , multiple waits, and
even shared VSAM files. (I called it a mini CICS)
I started chopping it up yesterday to get the bare essentials for Multi-user
full screen interface.

Shouldn't take to long to get it working to that point.

Hope that the SIO and channels work similar to what worked in SP/5
I'll keep all informed if I have any positive progress.


I'll try to build it so that it will be application independent and that
applications will work like transactions.
That might take longer.

Wife doen't have much planned for me this month so it might be doable in
that time frame.

Any body have the source for a nice editor.
if not:

What's the "minimum" that we want from an editior .
Just manual fixes in full screen mode and find and locate.?
if we get that far then we can expand it later.


Roc

_____

From: H390-VM-***@public.gmane.org [mailto:H390-VM-***@public.gmane.org] On Behalf Of
Robert O'Hara
Sent: Saturday, July 03, 2010 04:38
To: H390-VM-***@public.gmane.org
Subject: [H390-VM] Fullscreen support for VM/370 Sixpack




I thought I'd continue the discussion with a new subject since KICKS has
other issues besides fullscreen support. After reading the long discussion,
let me try and summarize:

1. Many people would love to see fullscreen 3270 support. This would allow a
fullscreen editor to be created. It would allow other programs that rely on
fullscreen interaction to be ported to VM/370.

2. Duplicating the support for this that IBM created is a LOT of work:
several large modules in CP. As Dave Wade has pointed out, the comparatively
simple changes to get highlighting in EDIT to work were themselves quite
difficult. I am somewhat familiar with the problem, and I agree with Dave,
this is hard code to write and to get right. For us hobbyists I think it is
not practical.

3. There are alternative solutions possible. Each has strengths and
weaknesses, which we might explore.

Perhaps we can divide the solution space up for clearer discussion. Here is
my take at possible solutions. Perhaps there are others out there!

Type 1: Dial support

If we have a CMS application that does 3270 I/O to an attached 3270 instead
of the console, then many problems go away. There is no issue switching
between "line mode" managed by CP and "fullscreen mode" managed by the
application, because they are running on separate terminals.

Pro: Not too hard to implement, I think. If you have source code for 3270
programs, not much modification required, I suspect. It might even be
possible to bury this code inside DIAG 58 and thus make it highly compatible
to what IBM has done.

Con: Not sure about the last point above, investigation needed. Thus this
may not be compatible with VM/SP or z/VM...

Type 2: Write a better terminal emulator

Mike Noel proposed this yesterday: embed 3270 data streams in the linemode
console data stream, and have a modfied terminal emulator that does the
right thing.

Pro: Similar to type 1 above.

Con: Similar to type 1, above.

Type 3: Forget the 3270

Paul Edwards has pointed out that it is straightforward to download the file
you want to edit to an editor running on your local OS (Windows, Linux,
etc). I work this way every day: My VMConsole program supports automatic
download of CMS files to a Windows editor, and when I save it on Windows it
is automatically uploaded to CMS. Any modern PC editor will run rings around
a 3270-based editor, of course.

Also, VMConsole today lets you pop-up a Windows dialog box from CMS. This
clearly could be extended to support forms-based input.

Pro: Easy to implement, as it is already working.

Con: Not really 3270 support at all.

Well, those are my thoughts.

Bob O'Hara

[kerravon86]

Post by Rocky
What's the "minimum" that we want from an editior .

That when I press the "x" key, an "x" appears on
the screen, instead of having it beep at me.

That rules out "vi".

One day Unix will catch up to MVS, that I can go
to any Unix box and have such a beast (e.g.
SPF/PC, emacs, both are "non-beepers").

At my current place of employment, about 80% of
the boxes I need to use I only have that "beeper"
program, and that "beeper" program can't even
handle me putting my xterm to fullscreen.

Fortunately, on the box that I do my programming
etc, emacs is available, so I can generally work
productively.

BFN. Paul.

[Mike Stramba]

Post by Rocky
I have an old application that I wrote back in early 80's that supported
Multiple terminals in full screen from dial mode as well as support for lots
of other goodies.
Pseudo multi tasking, storage control for getmains , multiple waits, and
even shared VSAM files. (I called it a mini CICS)
I started chopping it up yesterday to get the bare essentials for Multi-user
full screen interface.

Is it possible to issue a DIAL from a v.m. ?

I tried running an assembler program that executed a DIAG 8 with a
'DIAL CPWATCH' as the CP command, but instead of displaying the
CPWATCH screen (like what happens if I enter DIAL CPWATCH from a
logged off terminal), I just got a return code of 31072).

[Martin Trübner]

Mike,

Is it possible to issue a DIAL from a v.m. ?...
....I just got a return code of 31072).

I use VM since 77 and I never tried a DIAL while being logged on as a
CMS (or VSE) machine. I do not expect it to be honored by VM.

Talking about it:

...it could be honored by disconnecting the issuing user and then
simulating a DIAL on the now "unused" terminal.

This in fact could have been a solution to the problem of starting a
guest-op-sys where you need to do something before it starts to IPL in
CMS (i.e. coupling CTCAs). This problem was fixed by issuing inventing a
command "CONMODE 3270" for the console- which makes it available as
regular 3270 screen.

[Dave Wade]

----- Original Message -----
From: "Mike Stramba" <mikestramba-***@public.gmane.org>
To: <H390-VM-***@public.gmane.org>
Sent: Saturday, July 03, 2010 8:31 AM
Subject: Re: [H390-VM] Fullscreen support for VM/370 Sixpack

Post by Mike Stramba

Post by Rocky
I have an old application that I wrote back in early 80's that supported
Multiple terminals in full screen from dial mode as well as support for lots
of other goodies.
Pseudo multi tasking, storage control for getmains , multiple waits, and
even shared VSAM files. (I called it a mini CICS)
I started chopping it up yesterday to get the bare essentials for Multi-user
full screen interface.

Is it possible to issue a DIAL from a v.m. ?

NO, Like logon its ONLY valid when not logged on.
There are commnds that work in either state, MSG for example...

Post by Mike Stramba
I tried running an assembler program that executed a DIAG 8 with a
'DIAL CPWATCH' as the CP command, but instead of displaying the
CPWATCH screen (like what happens if I enter DIAL CPWATCH from a
logged off terminal), I just got a return code of 31072).
------------------------------------
Yahoo! Groups Links

[Rocky]

Post by Mike Stramba
Is it possible to issue a DIAL from a v.m. ?

Thats the easy part. so is the terminal io.

The more difficult stuff is getting a Program check handler and hanadling
the multi tasking.
As in any mult tasking environment - debugging is a real problem. If its
going to be at all useful it needs to have tools for that.
Roc


_____

From: H390-VM-***@public.gmane.org [mailto:H390-VM-***@public.gmane.org] On Behalf Of
Mike Stramba
Sent: Saturday, July 03, 2010 10:32
To: H390-VM-***@public.gmane.org
Subject: Re: [H390-VM] Fullscreen support for VM/370 Sixpack

Post by Mike Stramba
I have an old application that I wrote back in early 80's that supported
Multiple terminals in full screen from dial mode as well as support for lots
of other goodies.
Pseudo multi tasking, storage control for getmains , multiple waits, and
even shared VSAM files. (I called it a mini CICS)
I started chopping it up yesterday to get the bare essentials for Multi-user
full screen interface.

Is it possible to issue a DIAL from a v.m. ?

I tried running an assembler program that executed a DIAG 8 with a
'DIAL CPWATCH' as the CP command, but instead of displaying the
CPWATCH screen (like what happens if I enter DIAL CPWATCH from a
logged off terminal), I just got a return code of 31072).

[Mike Ward]

I think what everyone is trying to tell you is that you can't dial from a logged on terminal. You need to issue dial before you log on.

--- On Sat, 7/3/10, Rocky <rocsystems-***@public.gmane.org> wrote:


From: Rocky <rocsystems-***@public.gmane.org>
Subject: RE: [H390-VM] Fullscreen support for VM/370 Sixpack
To: H390-VM-***@public.gmane.org
Date: Saturday, July 3, 2010, 3:24 AM


 

 Is it possible to issue a DIAL from a v.m. ?

Thats the easy part. so is the terminal io.
 
The more difficult stuff is getting a Program check handler and hanadling the multi tasking.
As in any mult tasking environment  - debugging is a real problem. If its going to be at all useful it needs to have tools for that.
Roc




From: H390-***@yahoogroups .com [mailto:H390- ***@yahoogroups. com] On Behalf Of Mike Stramba
Sent: Saturday, July 03, 2010 10:32
To: H390-***@yahoogroups .com
Subject: Re: [H390-VM] Fullscreen support for VM/370 Sixpack


 

I have an old application that I wrote back in early 80's that supported
Multiple terminals in full screen from dial mode as well as support for lots
of other goodies.
Pseudo multi tasking, storage control for getmains , multiple waits, and
even shared VSAM files. (I called it a mini CICS)
I started chopping it up yesterday to get the bare essentials for Multi-user
full screen interface.

Is it possible to issue a DIAL from a v.m. ?

I tried running an assembler program that executed a DIAG 8 with a
'DIAL CPWATCH' as the CP command, but instead of displaying the
CPWATCH screen (like what happens if I enter DIAL CPWATCH from a
logged off terminal), I just got a return code of 31072).

[Rocky]

Mike
I already replied to that.. Yes that is correct.

But I don't think the question you asked is excatly what you intended.
It all depends on what you call VM.

You cannot dial from CMS, Nor can you dial after you have logged on to the machine because then your terminal is attached to a different part of VM/CP.
But when you get that Big screen that says VM/370 you can dial instead of logon, That is also VM. VM is sending you that screen.

I understand you don't consider that VM but thats a matter of interpertation.

Just a matter of semantics.

Roc

_____

From: H390-VM-***@public.gmane.org [mailto:H390-VM-***@public.gmane.org] On Behalf Of Mike Ward
Sent: Sunday, July 04, 2010 05:11
To: H390-VM-***@public.gmane.org
Subject: RE: [H390-VM] Fullscreen support for VM/370 Sixpack





I think what everyone is trying to tell you is that you can't dial from a logged on terminal. You need to issue dial before you log on.

--- On Sat, 7/3/10, Rocky <rocsystems-***@public.gmane.org> wrote:




From: Rocky <rocsystems-***@public.gmane.org>
Subject: RE: [H390-VM] Fullscreen support for VM/370 Sixpack
To: H390-VM-***@public.gmane.org
Date: Saturday, July 3, 2010, 3:24 AM

Post by Mike Stramba
Is it possible to issue a DIAL from a v.m. ?

Thats the easy part. so is the terminal io.

The more difficult stuff is getting a Program check handler and hanadling the multi tasking.
As in any mult tasking environment - debugging is a real problem. If its going to be at all useful it needs to have tools for that.
Roc


_____

From: H390-***@yahoogroups .com [mailto:H390- ***@yahoogroups. com] On Behalf Of Mike Stramba
Sent: Saturday, July 03, 2010 10:32
To: H390-***@yahoogroups .com
Subject: Re: [H390-VM] Fullscreen support for VM/370 Sixpack

Post by Mike Stramba
I have an old application that I wrote back in early 80's that supported
Multiple terminals in full screen from dial mode as well as support for lots
of other goodies.
Pseudo multi tasking, storage control for getmains , multiple waits, and
even shared VSAM files. (I called it a mini CICS)
I started chopping it up yesterday to get the bare essentials for Multi-user
full screen interface.

Is it possible to issue a DIAL from a v.m. ?

I tried running an assembler program that executed a DIAG 8 with a
'DIAL CPWATCH' as the CP command, but instead of displaying the
CPWATCH screen (like what happens if I enter DIAL CPWATCH from a
logged off terminal), I just got a return code of 31072).

[Rocky]

As promised - I said I'd keep you informed if any progress.

Full Screen 3270 Dial is now working on the my Six Pack.

Of couse for testing its only the first screen which Is just a dummy with no
real useful application behind it, but works.
This version will support up to 20 sessions simultaneosly. each can be
doing a separate function or the sme function.


Now I need the application specs to continue.

Love to have some collaberation.

Roc

If anyone wants to look at it - Contact me offline


_____

From: Rocky [mailto:rocsystems-***@public.gmane.org]
Sent: Saturday, July 03, 2010 09:28
To: 'H390-VM-***@public.gmane.org'
Subject: RE: [H390-VM] Fullscreen support for VM/370 Sixpack


Bob,

Your summary is pretty much right on as far as I can see.
Actually there hasn't been much discussion of 3270 emulator but I think that
is unreal as you can't be emulator dependent and then hardware dependent.

On the positive side:

I have an old application that I wrote back in early 80's that supported
Multiple terminals in full screen from dial mode as well as support for lots
of other goodies.

Pseudo multi tasking, storage control for getmains , multiple waits, and
even shared VSAM files. (I called it a mini CICS)
I started chopping it up yesterday to get the bare essentials for Multi-user
full screen interface.

Shouldn't take to long to get it working to that point.

Hope that the SIO and channels work similar to what worked in SP/5
I'll keep all informed if I have any positive progress.


I'll try to build it so that it will be application independent and that
applications will work like transactions.
That might take longer.

Wife doen't have much planned for me this month so it might be doable in
that time frame.

Any body have the source for a nice editor.
if not:

What's the "minimum" that we want from an editior .
Just manual fixes in full screen mode and find and locate.?
if we get that far then we can expand it later.


Roc

_____

From: H390-VM-***@public.gmane.org [mailto:H390-VM-***@public.gmane.org] On Behalf Of
Robert O'Hara
Sent: Saturday, July 03, 2010 04:38
To: H390-VM-***@public.gmane.org
Subject: [H390-VM] Fullscreen support for VM/370 Sixpack




I thought I'd continue the discussion with a new subject since KICKS has
other issues besides fullscreen support. After reading the long discussion,
let me try and summarize:

1. Many people would love to see fullscreen 3270 support. This would allow a
fullscreen editor to be created. It would allow other programs that rely on
fullscreen interaction to be ported to VM/370.

2. Duplicating the support for this that IBM created is a LOT of work:
several large modules in CP. As Dave Wade has pointed out, the comparatively
simple changes to get highlighting in EDIT to work were themselves quite
difficult. I am somewhat familiar with the problem, and I agree with Dave,
this is hard code to write and to get right. For us hobbyists I think it is
not practical.

3. There are alternative solutions possible. Each has strengths and
weaknesses, which we might explore.

Perhaps we can divide the solution space up for clearer discussion. Here is
my take at possible solutions. Perhaps there are others out there!

Type 1: Dial support

If we have a CMS application that does 3270 I/O to an attached 3270 instead
of the console, then many problems go away. There is no issue switching
between "line mode" managed by CP and "fullscreen mode" managed by the
application, because they are running on separate terminals.

Pro: Not too hard to implement, I think. If you have source code for 3270
programs, not much modification required, I suspect. It might even be
possible to bury this code inside DIAG 58 and thus make it highly compatible
to what IBM has done.

Con: Not sure about the last point above, investigation needed. Thus this
may not be compatible with VM/SP or z/VM...

Type 2: Write a better terminal emulator

Mike Noel proposed this yesterday: embed 3270 data streams in the linemode
console data stream, and have a modfied terminal emulator that does the
right thing.

Pro: Similar to type 1 above.

Con: Similar to type 1, above.

Type 3: Forget the 3270

Paul Edwards has pointed out that it is straightforward to download the file
you want to edit to an editor running on your local OS (Windows, Linux,
etc). I work this way every day: My VMConsole program supports automatic
download of CMS files to a Windows editor, and when I save it on Windows it
is automatically uploaded to CMS. Any modern PC editor will run rings around
a 3270-based editor, of course.

Also, VMConsole today lets you pop-up a Windows dialog box from CMS. This
clearly could be extended to support forms-based input.

Pro: Easy to implement, as it is already working.

Con: Not really 3270 support at all.

Well, those are my thoughts.

Bob O'Hara

[Tony Harminc]

Post by Robert O'Hara
Type 1: Dial support
If we have a CMS application that does 3270 I/O to an attached 3270 instead of the console, then many problems go away.  There is no issue switching between "line mode" managed by CP and "fullscreen mode" managed by the application, because they are running on separate terminals.
Pro:  Not too hard to implement, I think.  If you have source code for 3270 programs, not much modification required, I suspect.

I'm not clear what modifications you are talking about.This works
today if you have an application program that can drive an attached or
dialed 3270.

Post by Robert O'Hara
It might even be possible to bury this code inside DIAG 58 and thus make it highly compatible to what IBM has done.

Do you mean that DIAG 58 would talk to the ATTACHed 3270 instead of
the logged-on one?

Post by Robert O'Hara
Con:  Not sure about the last point above, investigation needed.  Thus this may not be compatible with VM/SP or z/VM...

It wouldn't be incompatible, by definition. But if the incompatibility
was only that the terminal being driven was the secondary one, that
wouldn't be so bad. And you could have a setting for the virtual
machine to say so. TERM CONMODE SECONDARY or TERM CONMODE <virtual
device address> or something.

Post by Robert O'Hara
Type 2: Write a better terminal emulator
Mike Noel proposed this yesterday:  embed 3270 data streams in the linemode console data stream, and have a modfied terminal emulator that does the right thing.
Pro:  Similar to type 1 above.
Con:  Similar to type 1, above.

I think the con is much greater. There are many tn3270s out there, and
tying the fullscreen support to a particular one will quickly cut the
"market" way down. But see below.

Post by Robert O'Hara
Type 3: Forget the 3270
Paul Edwards has pointed out that it is straightforward to download the file you want to edit to an editor running on your local OS (Windows, Linux, etc).  I work this way every day:  My
VMConsole program supports automatic download of CMS files to a Windows editor, and when I save it on Windows it is automatically uploaded to CMS.  Any modern PC editor will run
rings around a 3270-based editor, of course.
Also, VMConsole today lets you pop-up a Windows dialog box from CMS.  This clearly could be extended to support forms-based input.
Pro:  Easy to implement, as it is already working.
Con:  Not really 3270 support at all.

And also perhaps more suitable to running an editor than to running
something like KICKS.

You have prompted a couple of thoughts. But first I think it will pay
to understand whether the target "market" is existing application
programs, or at least existing well understood APIs from newer VM
versions, or if it's the ability to write new CMS (or standalone under
VM) code that does fullscreen stuff on some terminal somewhere
somehow. This is really asking, as I did some days ago, what the
expected API is. If it's the DIAG 58 from VM/SP, then option 1 above
is fairly simple, and would let a number of existing programs run
almost immediately.

If the requirement is to support apps from other platforms (MVS, DOS?)
that understand the 3260 datastream, but expect to just pass it to an
API, and get data back in return, i.e. don't know anything about
channel programming, then there's a bit more to do, but it's still not
too bad. The API (VTAM-like? TSO TPUT-like?) would have to manage
building and running channel programs, deal with interrupts, and so
on.

There is of course another *very* widely understood and supported
datastream out there that can do all this and more, and that's
HTML/XML and friends. There is no need to write a new tn3270 because
everyone has a browser already, and some of them even have embedded
tn3270 programs. Certainly piping <x>ML through the 3215 console would
not be hard, and Hercules would need minimal changes to just fire it
over to the browser. This could be a new Hercules device type, but
seen by CP as a real 3215 or real 3270, and by CMS as a virtual 3215
with extras. Whether CP is in good enough shape to do reads for
largish amounts of data, I don't know. Right now I'll bet it has a
small buffer (80 or 120 bytes?) for real 3215s, and probably the same
for the virtual ones. And we know input from real 3270s is a problem.

Some thought needs to be given to the half vs full duplex nature of
the device. S/370 devices are architected to be half duplex, but you
can get the effect of full duplex if you are willing to multiplex and
turn the connection around quickly, but this is more a matter of the
nature of the API than driving the virtual device(s).

The device could even be a non-terminal - tape or CTC or...?

Tony H.

[kerravon86]

Post by Tony Harminc

Con:  Not sure about the last point above, investigation needed. > > Thus this may not be compatible with VM/SP or z/VM...

It wouldn't be incompatible, by definition.

Did you mean wouldn't be *compatible*? Regardless,
can you elaborate on that? What definition?

Post by Tony Harminc
But if the incompatibility
was only that the terminal being driven was the secondary one, that
wouldn't be so bad. And you could have a setting for the virtual
machine to say so. TERM CONMODE SECONDARY or TERM CONMODE <virtual
device address> or something.

Sounds good.

Post by Tony Harminc
expected API is. If it's the DIAG 58 from VM/SP, then option 1 above
is fairly simple, and would let a number of existing programs run
almost immediately.

"fairly simple"? Seems we've moved a significant
distance from the "lot of work" solutions
previously given to choose from.

Care to elaborate on why DIAG 58 is simple?

Post by Tony Harminc
There is of course another *very* widely understood and supported
datastream out there that can do all this and more, and that's
HTML/XML and friends.

Sounds like a novel idea, which could be useful for
some apps.

Perhaps there are existing apps that already put
out such a data stream and would suddenly start
working?

BFN. Paul.

[Adam Thornton]

Post by kerravon86

Post by Robert O'Hara

Con: Not sure about the last point above, investigation needed. >

Thus this may not be compatible with VM/SP or z/VM...
It wouldn't be incompatible, by definition.

Did you mean wouldn't be *compatible*? Regardless,
can you elaborate on that? What definition?

Here's my operational definition.

No, the question was not addressed to me, but it's something I feel has
been largely lost in the current rash of suggestions designed to make
Hercules act more like modern MVS-and-derivatives rather than like the
s370/390/390x architecture as documented in _Principles_:

"compatible" means, doesn't make life worse or impossible for any
operating system for the documented architecture.

That is, if your changes break VM, they are not compatible. If they
break VSE, they are not compatible. If they break Linux, they are not
compatible. If they break OpenSolaris, they are, guess what, not
compatible.

Adam

[Rocky]

Update about full screen in Dial.

The full screen part is pretty much solved and works nicely on multiple
terminals simultaneously running separate tasks.
Several folks have taken me up on the possibility to look at it and the
response has been positive.

Next question is about the application - First application - EDIT.

I had several ideas about how to do this, but I'd like some input from the
group



---- ABOUT THE APPLICATION
The Dialed terminal is actually running under CMSUSER (or any other user)
which is handling multiple terminal tasks and is running disconnected. So
How Do we EDIT a file thats on MAINTS 191 and simultaneously edit a file for
a different user on a different dialed in connection.

Had a couple of thoughts but I would like suggestions. (that are techincally
feasible without changing the OS or the Emulator)

A) sugggestion one is that when you dial in, you give a read password and a
disk ( MAINT 191 RMAINT) and the file that you want to edit.
The program will do a quick readonly Link, read the file into storage and
release the link- you do your editing in full screen and then on exit or
save, the edit file is sent to your reader.
Not bad - slightly cumbersome but a nice start.

B) DO we have VMCF installed? - From reading I see that it was available
from VM/370 Release 3
If the answer is "YES" then a possible procedure could look like this:

Start a local small VMCF program in Maint or any user -The program
establishes connectivity with the large application in CMSUSER and then
disconnects the terminal, then you dial in to the dial applicaton and
thoretically you actually have everything available that you have in maint
on the dialed in terminal using VMCF messaging -
Well in theory but certainly you can read files and tranfer data via VMCF

Not sure that I can catch the console output in maint but can definitely
give commands etc and read files.

The VMCF is a bit complicated but I have done that before and it's doable
as described, if we have VMCF that is fairly bug free in our release of
VM/370

C) a third possibility is to scale down the project. Run the dial program in
your machine. so only one terminal and no multitasking
Progam will immediatel disconnect and then when you get the VM logon you can
dial back tour own machine
Again you will have everything available. Sound elegant - have to change a
lot of logic but doable.
I origianally wanted a small CICS type machine for sever users sharing an
application or applications and files but this is doable also.

I oiginally estimated a month to get this far and I am way ahead of schedule
so there is time. As I said the DIAL was the easy part. Multitasking was
more difficult. This approach might be more useful for us as a group.
I don''t have to throw out the multitaskng and you can actually have limited
logon to your own machine

Any other thoughts ? how to do it - technically.- with the DIAL
configuration.

Roc










_____

.

<http://geo.yahoo.com/serv?s=97359714/grpId=2539927/grpspId=1705053800/msgId
=7255/stime=1278381693/nc1=1/nc2=2/nc3=3>

[rocsystems]

Rereading what I wrote previously - need to point out that one of the user requests brought up was that that we allow end users, programmer types, to write full screen applications -

Don't see this happening unless we can make a very standard programming interface to the full screen stuff that I am writing now - (for that I think we would need to do a lot of technical writing)

Question to the VM gurus - Can I run a command like "LISTF (exec " from inside an application.

If yes then would it be feasable to give the command from the dialed terminal application then read CMS exec in the same application
and then pass the results to full screen terminal.

If that is possible then it would be like a full screen flist and then you could go right into the editor.
Lots of possibilities here.


Really need input - from Dave and Ivan etc. Everyone else also, but keep it on the dial application solution, and the technical possibilities.

Also try to refrain from using the word simple or Paul will assume that means a one line change. :-)


Roc




roc

Post by Rocky
Update about full screen in Dial.
The full screen part is pretty much solved and works nicely on multiple
terminals simultaneously running separate tasks.
Several folks have taken me up on the possibility to look at it and the
response has been positive.
Next question is about the application - First application - EDIT.
I had several ideas about how to do this, but I'd like some input from the
group
---- ABOUT THE APPLICATION
The Dialed terminal is actually running under CMSUSER (or any other user)
which is handling multiple terminal tasks and is running disconnected. So
How Do we EDIT a file thats on MAINTS 191 and simultaneously edit a file for
a different user on a different dialed in connection.
Had a couple of thoughts but I would like suggestions. (that are techincally
feasible without changing the OS or the Emulator)
A) sugggestion one is that when you dial in, you give a read password and a
disk ( MAINT 191 RMAINT) and the file that you want to edit.
The program will do a quick readonly Link, read the file into storage and
release the link- you do your editing in full screen and then on exit or
save, the edit file is sent to your reader.
Not bad - slightly cumbersome but a nice start.
B) DO we have VMCF installed? - From reading I see that it was available
from VM/370 Release 3
Start a local small VMCF program in Maint or any user -The program
establishes connectivity with the large application in CMSUSER and then
disconnects the terminal, then you dial in to the dial applicaton and
thoretically you actually have everything available that you have in maint
on the dialed in terminal using VMCF messaging -
Well in theory but certainly you can read files and tranfer data via VMCF
Not sure that I can catch the console output in maint but can definitely
give commands etc and read files.
The VMCF is a bit complicated but I have done that before and it's doable
as described, if we have VMCF that is fairly bug free in our release of
VM/370
C) a third possibility is to scale down the project. Run the dial program in
your machine. so only one terminal and no multitasking
Progam will immediatel disconnect and then when you get the VM logon you can
dial back tour own machine
Again you will have everything available. Sound elegant - have to change a
lot of logic but doable.
I origianally wanted a small CICS type machine for sever users sharing an
application or applications and files but this is doable also.
I oiginally estimated a month to get this far and I am way ahead of schedule
so there is time. As I said the DIAL was the easy part. Multitasking was
more difficult. This approach might be more useful for us as a group.
I don''t have to throw out the multitaskng and you can actually have limited
logon to your own machine
Any other thoughts ? how to do it - technically.- with the DIAL
configuration.
Roc
_____
.
<http://geo.yahoo.com/serv?s=97359714/grpId=2539927/grpspId=1705053800/msgId
=7255/stime=1278381693/nc1=1/nc2=2/nc3=3>

[kerravon86]

Post by rocsystems
Don't see this happening unless we can make a very
standard programming interface to the full screen
stuff that I am writing now - (for that I think we
would need to do a lot of technical writing)

If you reuse DIAG 58, you can skip the writing.

Post by rocsystems
Question to the VM gurus

You called?

Post by rocsystems
Can I run a command like "LISTF (exec " from inside
an application.

Easy peasy, Japanesey, eat raw fish that make me squeasy.

(from pdpclib)
**********************************************************************
*
* @@SVC202 - ISSUES AN SVC 202 CALL
*
* E.G. @@SVC202(PARMS,CODE,ERROR)
*
* WHERE :-
*
* PARMS IS A POINTER TO AN SVC202 PARAMETER LIST
*
* CODE IS A CODE TO SAY OF &CONTROL IS ON OR OFF
*
* AND ERROR IS SET TO -1
*
**********************************************************************
ENTRY @@SVC202
@@SVC202 EQU *
SAVE (14,12),,@@SVC202
LR R12,R15
USING @@SVC202,R12
LR R11,R1 NEED TO RESTORE R1 FOR C
AIF ('&SYS' NE 'S380').NOMODS1
CALL @@SETM24
.NOMODS1 ANOP
L R3,0(R1) R3 POINTS TO SVC202 PARM LIST
L R4,4(R1) R4 POINTS TO CODE
L R5,8(R1) R5 POINTS TO RETURN CODE
SR R6,R6 CLEAR R6
ST R6,0(R5) AND SAVE IN RETURN CODE
LR R1,R3
*
AIF ('&SYS' EQ 'S390').DOCALL
SVC 202 ISSUE COMMAND
DC AL4(SV202ER) ERROR
AGO .FINCALL
.DOCALL ANOP
CMSCALL ERROR=SV202ER
.FINCALL ANOP
*
SV202RT EQU *
LR R7,R15
AIF ('&SYS' NE 'S380').NOMODS2
CALL @@SETM31
.NOMODS2 ANOP
LR R15,R7
LR R1,R11
RETURN (14,12),RC=(15)
SV202ER EQU *
L R3,=F'-1'
ST R3,0(R5)
B SV202RT
LTORG



static void fdclr(char *ddname)
{
char s202parm [800];
int code;
int parm;

/* build the SVC 202 string */
memcpy( &s202parm[0] , "FILEDEF ", 8);
memcpy( &s202parm[8] , ddname, 8);
memcpy( &s202parm[16] , "CLEAR ", 8);
memset( &s202parm[24], 0xff, 8);

__SVC202 ( s202parm, &code, &parm );
return;
}


And it looks to me like it's about time that was
made generic, ie to implement system().

Then you can do things like this (from ozpd):

sprintf(buf, "listfile %s (exec", filename);
system(buf);
fp = fopen("cms exec","r");

BFN. Paul.

[Rocky]

Obviously I know that I can run a CMS command or a CP command but the
question was more to the point if the LISTF command "specifically" will not
conflict with another application. and how will it affect writing to the
terminal when I am trapping all the interupts.
NOT all comands run the same - Especially if I am trapping interrupts to the
console in the main program.

LISTF can produce 30000 lines of Terminal output - can I trap that? or do I
need the EXEC option to get a cms file and then read that. you said - leave
it to the gurus -

Thought I made it plain that I am looking only for dial solutions.

Think you can forget about the DIAG58 interface support - Not simple amd no
one has picked up the task and said "I will do i"t-
and given a time line.
I may not live that long.

Unless someone say they will do it and give a time frame then it is a moot
discussion.

It wont give you anthing drastically different than the Option C that I
outlined in the memo.

You still have to write the same full screen application, still have to
handle the mapping still have trap interrupts.
You still have to run the program that does the diagnose - in your machine
You still have to write all funtions that you want to be full screen - Flist
Xedit etc. etc.
You are still limited to doing just the things that you programmed your
appliation to do;
You are not a free cms user on a full screen terminal
.
You are not a full screen VM terminal but a full screen terminal talking to
a specific application.

The difference between the two approaches is:
with DIAG 58 :
you will run a program
that program will send you a screen and then
you can do whatever that screen and program allow you to do or have been
programmed to do.
On exit of the program, you are back in CMS

with Dial ( as in option C:)
you run a program
that program Disconnects the consol
You get the VM/screen and immediately do dial to your user ID
that program will send you a screen and then
you can do whatever that screen and program allow you to do
On exit of the program you are back in VM and you do logon to reconnect to
your user

.
Option for DIAG definitely has some PROS
BUT the CON is that it doesn't exist and no sign that it will exist in the
near future

Option for dial is functionally equivalent but with two more steps in the
procedure
PRO is that that its doable with out any changes to CP or CMS
Con is the same extra two steps


Roc


_____

From: H390-VM-***@public.gmane.org [mailto:H390-VM-***@public.gmane.org] On Behalf Of
kerravon86
Sent: Tuesday, July 06, 2010 15:53
To: H390-VM-***@public.gmane.org
Subject: [H390-VM] Re: Fullscreen support for VM/370 Sixpack - UPdate

Post by rocsystems
Don't see this happening unless we can make a very
standard programming interface to the full screen
stuff that I am writing now - (for that I think we
would need to do a lot of technical writing)

If you reuse DIAG 58, you can skip the writing.

Post by rocsystems
Question to the VM gurus

You called?

Post by rocsystems
Can I run a command like "LISTF (exec " from inside
an application.

Easy peasy, Japanesey, eat raw fish that make me squeasy.

(from pdpclib)
**********************************************************************
*
* @@SVC202 - ISSUES AN SVC 202 CALL
*
* E.G. @@SVC202(PARMS,CODE,ERROR)
*
* WHERE :-
*
* PARMS IS A POINTER TO AN SVC202 PARAMETER LIST
*
* CODE IS A CODE TO SAY OF &CONTROL IS ON OR OFF
*
* AND ERROR IS SET TO -1
*
**********************************************************************
ENTRY @@SVC202
@@SVC202 EQU *
SAVE (14,12),,@@SVC202
LR R12,R15
USING @@SVC202,R12
LR R11,R1 NEED TO RESTORE R1 FOR C
AIF ('&SYS' NE 'S380').NOMODS1
CALL @@SETM24
.NOMODS1 ANOP
L R3,0(R1) R3 POINTS TO SVC202 PARM LIST
L R4,4(R1) R4 POINTS TO CODE
L R5,8(R1) R5 POINTS TO RETURN CODE
SR R6,R6 CLEAR R6
ST R6,0(R5) AND SAVE IN RETURN CODE
LR R1,R3
*
AIF ('&SYS' EQ 'S390').DOCALL
SVC 202 ISSUE COMMAND
DC AL4(SV202ER) ERROR
AGO .FINCALL
.DOCALL ANOP
CMSCALL ERROR=SV202ER
.FINCALL ANOP
*
SV202RT EQU *
LR R7,R15
AIF ('&SYS' NE 'S380').NOMODS2
CALL @@SETM31
.NOMODS2 ANOP
LR R15,R7
LR R1,R11
RETURN (14,12),RC=(15)
SV202ER EQU *
L R3,=F'-1'
ST R3,0(R5)
B SV202RT
LTORG

static void fdclr(char *ddname)
{
char s202parm [800];
int code;
int parm;

/* build the SVC 202 string */
memcpy( &s202parm[0] , "FILEDEF ", 8);
memcpy( &s202parm[8] , ddname, 8);
memcpy( &s202parm[16] , "CLEAR ", 8);
memset( &s202parm[24], 0xff, 8);

__SVC202 ( s202parm, &code, &parm );
return;
}

And it looks to me like it's about time that was
made generic, ie to implement system().

Then you can do things like this (from ozpd):

sprintf(buf, "listfile %s (exec", filename);
system(buf);
fp = fopen("cms exec","r");

BFN. Paul.

[gm1mqe]

In the VM system at Greenock I zapped CP code to allow a special user (We used class H) to be able to link ANY minidisk with a master password, rather three read write and multi. These passwords were hard coded but changed at times via an edit the nuc build. This was used for some security stuff I dont want to talk about! If we allowed the edit user ID to use this it can get access to any cms disk. Not sure how we would ensure that only the owner can access the disks but it could be done I am sure. Perhaps in our "hobbist" user it would not matter to protect access?

Andy

[Rocky]

That sounds great - Actually my approach was that the user logons on to the
the dial application with his real USER-ID and Password.
Which I compare to the VM directory or a copy of the vm directroy which the
DIAL machine has access to.
then Detach --- But that is moot if we use option "C".

If we stick with option "A" I Like your approach better.

Lets see what the consensus is
Roc


_____

From: H390-VM-***@public.gmane.org [mailto:H390-VM-***@public.gmane.org] On Behalf Of
gm1mqe
Sent: Tuesday, July 06, 2010 16:55
To: H390-VM-***@public.gmane.org
Subject: [H390-VM] Re: Fullscreen support for VM/370 Sixpack - UPdate




In the VM system at Greenock I zapped CP code to allow a special user (We
used class H) to be able to link ANY minidisk with a master password, rather
three read write and multi. These passwords were hard coded but changed at
times via an edit the nuc build. This was used for some security stuff I
dont want to talk about! If we allowed the edit user ID to use this it can
get access to any cms disk. Not sure how we would ensure that only the owner
can access the disks but it could be done I am sure. Perhaps in our
"hobbist" user it would not matter to protect access?

Andy

[Robert O'Hara]

Wait! Wait! Don't do it yet!

A couple of points. First of all, having two virtual machines linked read/write to the same minidisk is a recipe for disaster. The files on the disk will become scrambled and the contents destroyed. I can explain this problem in WAY more detail if you are interested.

Secondly, I'm not convinced that the fullscreen editor needs to run in a separate virtual machine. As was already demonstrated earlier in this thread, it is possible from a CMS user's machine (with appropriate CP priviledges) to
1. Disable an "extra" 3270 terminal at a specific address
CP DISABLE 2C2
2. Attach the terminal to the current virtual machine
CP ATTACH 2C2 TO MAINT AS 2C2
3. Enable the terminal
CP ENABLE 2C2
At this point, I believe that a CMS program (an editor, for example) could then to SIOs to that attached device.

Thus the full screen editor is just another CMS program. It just happens to address the second screen attached to the user's machine. So you would use your "main" terminal to issue commands, and when you issued the new editor command, the second terminal would light up and you would switch to it to edit the file.

Thus there is no need for a separate virtual machine to be running. This is all just a simple matter of 370 and 3270 I/O programming.

Or am I missing something???

Bob

Post by Rocky
That sounds great - Actually my approach was that the user logons on to the
the dial application with his real USER-ID and Password.
Which I compare to the VM directory or a copy of the vm directroy which the
DIAL machine has access to.
then Detach --- But that is moot if we use option "C".
If we stick with option "A" I Like your approach better.
Lets see what the consensus is
Roc
_____
gm1mqe
Sent: Tuesday, July 06, 2010 16:55
Subject: [H390-VM] Re: Fullscreen support for VM/370 Sixpack - UPdate
In the VM system at Greenock I zapped CP code to allow a special user (We
used class H) to be able to link ANY minidisk with a master password, rather
three read write and multi. These passwords were hard coded but changed at
times via an edit the nuc build. This was used for some security stuff I
dont want to talk about! If we allowed the edit user ID to use this it can
get access to any cms disk. Not sure how we would ensure that only the owner
can access the disks but it could be done I am sure. Perhaps in our
"hobbist" user it would not matter to protect access?
Andy

[Tony Harminc]

Secondly, I'm not convinced that the fullscreen editor needs to run in a separate virtual machine.  As was already demonstrated earlier in this thread, it is possible from a CMS user's machine (with appropriate CP priviledges) to
  1. Disable an "extra" 3270 terminal at a specific address
     CP DISABLE 2C2
  2. Attach the terminal to the current virtual machine
     CP ATTACH 2C2 TO MAINT AS 2C2
  3. Enable the terminal
     CP ENABLE 2C2

I believe that last command is going to fail; you can't ENable a
device that is ATTACHed to a virtual machine. Perhaps you're thinking
of VARY ON/VARY OFF?

At this point, I believe that a CMS program (an editor, for example) could then to SIOs to that attached device.

Yes, but you need the device to be VARY'd ON but DISabled to ATTACH
it. But if you want to DIAL it it must be ENabled. Perhaps you're
conflating the two?

Tony H.

[Robert O'Hara]

Tony,

I **think** I understand the difference. But whether I DIAL from a terminal to a virtual machine, or from that virtual machine ATTACH a terminal, in the end, the virtual machine now has a 3270 at some address. And now I can run a program that does I/O to and from that address. Correct?

Bob

Post by Tony Harminc

Secondly, I'm not convinced that the fullscreen editor needs to run in a separate virtual machine.  As was already demonstrated earlier in this thread, it is possible from a CMS user's machine (with appropriate CP priviledges) to
  1. Disable an "extra" 3270 terminal at a specific address
     CP DISABLE 2C2
  2. Attach the terminal to the current virtual machine
     CP ATTACH 2C2 TO MAINT AS 2C2
  3. Enable the terminal
     CP ENABLE 2C2

I believe that last command is going to fail; you can't ENable a
device that is ATTACHed to a virtual machine. Perhaps you're thinking
of VARY ON/VARY OFF?

At this point, I believe that a CMS program (an editor, for example) could then to SIOs to that attached device.

Yes, but you need the device to be VARY'd ON but DISabled to ATTACH
it. But if you want to DIAL it it must be ENabled. Perhaps you're
conflating the two?
Tony H.

[Ivan Warren]

Post by Robert O'Hara
Tony,
I **think** I understand the difference. But whether I DIAL from a terminal to a virtual machine, or from that virtual machine ATTACH a terminal, in the end, the virtual machine now has a 3270 at some address. And now I can run a program that does I/O to and from that address. Correct?
Bob

I'm not Tony..

But the answer is :

YES !

--Ivan

[Tony Harminc]

Tony,
I **think** I understand the difference.  But whether I DIAL from a terminal to a virtual machine, or from that virtual machine ATTACH a terminal,

Or from any other suitably privileged userid, since you are dealing
with a real device in that case

in the end, the virtual machine now has a 3270 at some address.  And now I can run a program that does I/O to and from that address.  Correct?

Yup. And that terminal has nothing at all to do with the VM console
that you used to log on, and from which you control your virtual
machine's front panel knobs & switches.

Or to use another example, the program you run to do the I/O could be,
say, MVS with TSO. Or your own home-grown standalone editor. Or CMS
with your own application program. Etc.

Bob

Tony H.

Post by Tony Harminc

Secondly, I'm not convinced that the fullscreen editor needs to run in a separate virtual machine.  As was already demonstrated earlier in this thread, it is possible from a CMS user's machine (with appropriate CP priviledges) to
  1. Disable an "extra" 3270 terminal at a specific address
     CP DISABLE 2C2
  2. Attach the terminal to the current virtual machine
     CP ATTACH 2C2 TO MAINT AS 2C2
  3. Enable the terminal
     CP ENABLE 2C2

I believe that last command is going to fail; you can't ENable a
device that is ATTACHed to a virtual machine. Perhaps you're thinking
of VARY ON/VARY OFF?

At this point, I believe that a CMS program (an editor, for example) could then to SIOs to that attached device.

Yes, but you need the device to be VARY'd ON but DISabled to ATTACH
it. But if you want to DIAL it it must be ENabled. Perhaps you're
conflating the two?
Tony H.

[Ivan Warren]

Post by Robert O'Hara
Tony,
I **think** I understand the difference. But whether I DIAL from a terminal to a virtual machine, or from that virtual machine ATTACH a terminal, in the end, the virtual machine now has a 3270 at some address. And now I can run a program that does I/O to and from that address. Correct?
Bob

Ok Bob, To be more accurate and thorough on this subject :

- A "Defined" GRAF 'whether it be through the DEFINE GRAF command or the
SPECIAL statement in the directory) to which no 3270 has dialed will
always return Unit Check on initial status for any CCW (except Sense
CCWs). On "Hercules" there is a slight flaw - in the sense that this
should also be returned on TIO (with CC=1) and SIO (also with CC=1)
whereas on hercules, the CSW is only returned as a separate interrupt on
SIO (and TIO gives CC=0). All Operating systems we know handle this
correctly as it is a *possible* situation (the device turning off after
the SIO was issued but before the CCW is received).

- A Dedicated terminal will behave the same if the terminal is not ON
(on a 3x74 : the terminal is switched off, on hercules : no one has made
a TN3270 connection to the device). The 2 situations are the same - A
terminal definition exists, but the terminal isn't actually available.

- Once a terminal DIALs in, the terminal is turned on (on a real 3x74)
or a TN3270 session is established on the device, an unsolicited Device
End Status will be presented to the CPU (and in VM, Virtual Machine CPU)
to indicate the NOT-READY to READY transition. This is how a Channel
Attached Control Unit specifies to a S/370, S/390 or z/Arch system that
a device has gone from the not-ready to ready status.

- Once the terminal is ON (Powered On for a 3x74, Dialed for a VM
terminal connection or the TN3270 session has been established), you may
issue I/Os to that terminal direction using normal I/O procedure for the
S/370 architecture (SIO, TIO, etc..)

--Ivan

[Dave Wade]

Post by Dave Wade
----- Original Message -----
Sent: Tuesday, July 06, 2010 6:34 PM>
Subject: [H390-VM] Re: Fullscreen support for VM/370 Sixpack - UPdate
Tony,
I **think** I understand the difference. But whether I DIAL from a

terminal to a virtual machine, or from that virtual machine ATTACH a
terminal, in the end, >the virtual machine now has a 3270 at some address.

Yes, how it gets there isn't important....

Post by Dave Wade
And now I can run a program that does I/O to and from that address.

Correct?

Correct. Thats what happens when you run any OS other than CMS in a Virtual
Machine, so its just the same in CMS ...

Post by Dave Wade
Bob

Post by Robert O'Hara
Secondly, I'm not convinced that the fullscreen editor needs to run in a

separate virtual machine. As was already demonstrated earlier in this
thread, it is possible from a CMS user's machine (with appropriate CP
priviledges) to

Post by Dave Wade

Post by Robert O'Hara
1. Disable an "extra" 3270 terminal at a specific address
CP DISABLE 2C2
2. Attach the terminal to the current virtual machine
CP ATTACH 2C2 TO MAINT AS 2C2
3. Enable the terminal
CP ENABLE 2C2

I believe that last command is going to fail; you can't ENable a
device that is ATTACHed to a virtual machine. Perhaps you're thinking
of VARY ON/VARY OFF?

Post by Robert O'Hara
At this point, I believe that a CMS program (an editor, for example)

could then to SIOs to that attached device.

Post by Dave Wade
Yes, but you need the device to be VARY'd ON but DISabled to ATTACH
it. But if you want to DIAL it it must be ENabled. Perhaps you're
conflating the two?
Tony H.

[Rocky]

this question seems to have gotten mislaid in all the excitement.

Waht about the VMCF - wherther its an alternative or not is irrelvant.
Does it exist on our version ot the SIX-PACK

I saw an article that it existed from VM/370 release 3

any help on if it exists and what condition it's in

ROC

_____

From: H390-VM-***@public.gmane.org [mailto:H390-VM-***@public.gmane.org] On Behalf Of
Dave Wade
Sent: Tuesday, July 06, 2010 21:11
To: H390-VM-***@public.gmane.org
Subject: Re: [H390-VM] Re: Fullscreen support for VM/370 Sixpack - UPdate

Post by Dave Wade
----- Original Message -----

<mailto:rohara%40andrewseybold.com> >

Post by Dave Wade
Sent: Tuesday, July 06, 2010 6:34 PM>
Subject: [H390-VM] Re: Fullscreen support for VM/370 Sixpack - UPdate
Tony,
I **think** I understand the difference. But whether I DIAL from a

terminal to a virtual machine, or from that virtual machine ATTACH a
terminal, in the end, >the virtual machine now has a 3270 at some address.

Yes, how it gets there isn't important....

Post by Dave Wade
And now I can run a program that does I/O to and from that address.

Correct?

Correct. Thats what happens when you run any OS other than CMS in a Virtual
Machine, so its just the same in CMS ...

Post by Dave Wade
Bob

Post by Robert O'Hara
Secondly, I'm not convinced that the fullscreen editor needs to run in a

separate virtual machine. As was already demonstrated earlier in this
thread, it is possible from a CMS user's machine (with appropriate CP
priviledges) to

Post by Dave Wade

Post by Robert O'Hara
1. Disable an "extra" 3270 terminal at a specific address
CP DISABLE 2C2
2. Attach the terminal to the current virtual machine
CP ATTACH 2C2 TO MAINT AS 2C2
3. Enable the terminal
CP ENABLE 2C2

I believe that last command is going to fail; you can't ENable a
device that is ATTACHed to a virtual machine. Perhaps you're thinking
of VARY ON/VARY OFF?

Post by Robert O'Hara
At this point, I believe that a CMS program (an editor, for example)

could then to SIOs to that attached device.

Post by Dave Wade
Yes, but you need the device to be VARY'd ON but DISabled to ATTACH
it. But if you want to DIAL it it must be ENabled. Perhaps you're
conflating the two?
Tony H.

[Ivan Warren]

Post by Rocky
this question seems to have gotten mislaid in all the excitement.
Waht about the VMCF - wherther its an alternative or not is irrelvant.
Does it exist on our version ot the SIX-PACK
I saw an article that it existed from VM/370 release 3
any help on if it exists and what condition it's in
ROC

VMCF (Virtual Machine Communication Facility) exists in VM/370 R6. It is
actually necessary even just to process SMSG requests.

However, VMCF lacks the notion of a session - so is basically a
ConnectionLess protocol.. IUCV (Inter User Communication Vehicle) came
later to circumvent that (or to supplement).

--Ivan

[Rocky]

Ivan

I really am having trouble follwing your logic. (on all topics) must be
getting senile.
Way too much information for my simple mind. But since you are usually
correct I am trying to understand it.

====================================================================
What does the session issue have to do with the application in VMCF.
I have a VMCF application that worked for 25 years on VM SP/5 . VMCF not
IUCV.

Actually a program that was running in one machine had the abilty to do
reads an writes to a VSAM file via the VMCF application(s) that existed in
both machines.

In this case one machine owned the VSAM files and the other machine(s)
(several of them actually) passed data and control fields and did reads and
writes on the same File.
That way we we had several CMS virtual machines updating one VSAM file all
day with no need to shut down the main application that ran 24/7 ( btw the
same sio logic that I am talking about here.)
Similar to a multiuser online applicaton and batch application updating a
file simultaneously
(I develpped that logic 20 years ago and DBCNTL seems to using the same
messaging logic today) - with different tools - but messaging.

There was no session - that is true, but there was a connection and a reply,
which is all you really need.
SMSG was not secure but SEND RECEIVE were and and the reciever had to
authorize the sending machine as I remember it.

Pretty much similar to what MQ does today.

VMCF in SP/5 had . SEND/RECV support which was the ability to request a
reply so that was a complete conversation.
True only the one side could initiate a conversation but that was/is
application logic.
VMCF back then supported SEND RECV as well as the SMSG funtion - Completely
different animals.
==============================================================
As for the sio and dial as opposed to the attach. Makes no diference in my
opinion.
If we put "def graf 491 3270 " in the profile exec the virtual device 491
will be there.
If you do attach 333 maint 491 the virtual device will be there.

If you open two sessions in your modern emulator and logon to the user with
one, and dial to the user with the other you have accomplished exactly the
same thing as all the hardware manipulation.
When you start the application The CMS console will be attached to the
application in line mode, the other in FULL SCREEN MODE .

True you have a complete virtual environment - in both cases - but you can
only do what your application permits you to do, unless you break into CP
and bypass the application - so you can execute CP commands.

While your application is running - the only way you can really use the
3215 is thru your application. In both cases. No difference.

At this point we are in the same position either way.

If there is an application that talks to virtual 491 it will recognize the
terminal whether its dialed or attached.
To follow your logic - you only have to do the dial once, same time as you
logon on to the other graf.

The only difference being that if you logoff from the user machine in the
case of DIAL - VM will drop the session - To get it back you dial again
when you logon again.
Which is three words -- d maint 491

The hadware solution seems much more complicated and needs system
intevention where none is really needed.
About the virtual address you are correct. But it is the physical address
that is problematcal.

If you are going to do attach then you have to Know the physical address.
Which again means either go look at at it manually after you are in the
machine - or pick it up from hercules somehow -(finally a good use use for
DIAG 8)

And then do the attach accordingly - The problem is not on Virtual Side -
The problem is on the physical side -
If you want to automate it, you have to get to the same physical terminal
each time.
And then you would have to reserve that address in the TCPIP routines on
Hercules somehow so that it wouldn’t go to sombody else.
Fine for one user but more complicated if you have ten. (or More)
And then you have to set the emulator up to request the same address from
Hercules. All doable ....

Seems like it s a lot more comlicated than DIAL maint 491. when you start
the second session.


But the bottom line is that none of this has anything to do with the
application. Its all transparent.

Do we write the application in the users machine or do we write the
application in a separate machine and do all the connectivity from there.



Roc


-----Original Message-----
From: H390-VM-***@public.gmane.org [mailto:H390-VM-***@public.gmane.org] On Behalf Of
Ivan Warren
Sent: Tuesday, July 06, 2010 21:58
To: H390-VM-***@public.gmane.org
Subject: Re: [H390-VM] Re: Fullscreen support for VM/370 Sixpack - UPdate

Post by Rocky
this question seems to have gotten mislaid in all the excitement.
Waht about the VMCF - wherther its an alternative or not is irrelvant.
Does it exist on our version ot the SIX-PACK
I saw an article that it existed from VM/370 release 3
any help on if it exists and what condition it's in
ROC

VMCF (Virtual Machine Communication Facility) exists in VM/370 R6. It is
actually necessary even just to process SMSG requests.

However, VMCF lacks the notion of a session - so is basically a
ConnectionLess protocol.. IUCV (Inter User Communication Vehicle) came later
to circumvent that (or to supplement).

--Ivan

[Tony Harminc]

Post by Ivan Warren
VMCF (Virtual Machine Communication Facility) exists in VM/370 R6. It is
actually necessary even just to process SMSG requests.
However, VMCF lacks the notion of a session - so is basically a
ConnectionLess protocol.. IUCV (Inter User Communication Vehicle) came later
to circumvent that (or to supplement).

TCP is built upon an even worse substrate - a connectionless protocol
that is also unreliable. VMCF is not connection oriented, but it is
reliable, i.e. knows when it has worked and when it has failed, and
can report back.

Tony H.

[Dave Wade]

VMCF exists and works



Dave Wade G4UGM

Illegitimi Non Carborundum



-----Original Message-----
From: H390-VM-***@public.gmane.org [mailto:H390-VM-***@public.gmane.org] On Behalf Of
Rocky
Sent: 06 July 2010 19:54
To: H390-VM-***@public.gmane.org
Subject: RE: [H390-VM] Re: Fullscreen support for VM/370 Sixpack - UPdate




this question seems to have gotten mislaid in all the excitement.

Waht about the VMCF - wherther its an alternative or not is irrelvant.
Does it exist on our version ot the SIX-PACK

I saw an article that it existed from VM/370 release 3

any help on if it exists and what condition it's in

ROC

_____

From: H390-VM-***@public.gmane.org [mailto:H390-VM-***@public.gmane.org] On Behalf Of
Dave Wade
Sent: Tuesday, July 06, 2010 21:11
To: H390-VM-***@public.gmane.org
Subject: Re: [H390-VM] Re: Fullscreen support for VM/370 Sixpack - UPdate

Post by Dave Wade
----- Original Message -----

<mailto:rohara%40andrewseybold.com> >

Post by Dave Wade
Sent: Tuesday, July 06, 2010 6:34 PM>
Subject: [H390-VM] Re: Fullscreen support for VM/370 Sixpack - UPdate
Tony,
I **think** I understand the difference. But whether I DIAL from a

terminal to a virtual machine, or from that virtual machine ATTACH a
terminal, in the end, >the virtual machine now has a 3270 at some address.

Yes, how it gets there isn't important....

Post by Dave Wade
And now I can run a program that does I/O to and from that address.

Correct?

Correct. Thats what happens when you run any OS other than CMS in a Virtual
Machine, so its just the same in CMS ...

Post by Dave Wade
Bob

Post by Robert O'Hara
Secondly, I'm not convinced that the fullscreen editor needs to run in a

separate virtual machine. As was already demonstrated earlier in this
thread, it is possible from a CMS user's machine (with appropriate CP
priviledges) to

Post by Dave Wade

Post by Robert O'Hara
1. Disable an "extra" 3270 terminal at a specific address
CP DISABLE 2C2
2. Attach the terminal to the current virtual machine
CP ATTACH 2C2 TO MAINT AS 2C2
3. Enable the terminal
CP ENABLE 2C2

I believe that last command is going to fail; you can't ENable a
device that is ATTACHed to a virtual machine. Perhaps you're thinking
of VARY ON/VARY OFF?

Post by Robert O'Hara
At this point, I believe that a CMS program (an editor, for example)

could then to SIOs to that attached device.

Post by Dave Wade
Yes, but you need the device to be VARY'd ON but DISabled to ATTACH
it. But if you want to DIAL it it must be ENabled. Perhaps you're
conflating the two?
Tony H.

[Mike Stramba]

I don't see anything on bitsavers titled either VMCF, or Virtual
Machine Communications Facility, is it documented inside another
manual?

Post by Dave Wade
VMCF exists and works
-----Original Message-----
Rocky
Sent: 06 July 2010 19:54
Subject: RE: [H390-VM] Re: Fullscreen support for VM/370 Sixpack - UPdate
this question seems to have gotten mislaid in all the excitement.
What about the VMCF - wherther its an alternative or not is irrelvant.
Does it exist on our version ot the SIX-PACK

[Tony Harminc]

I don't  see anything on bitsavers titled either VMCF, or Virtual
Machine Communications Facility, is it documented inside another
manual?

It's in the System Programmer's Guide.
http://bitsavers.org/pdf/ibm/370/vm370/GC20-1807-7_VM370syPgm_4-81.pdf

Or you can look in the modern IBM doc - the CP Programming Services
book is the one..

Tony H.

[Dave Wade]

Yes, but I don't remember which, its a CP facility so probably Systems
Programmers...

----- Original Message -----
From: "Mike Stramba" <mikestramba-***@public.gmane.org>
To: <H390-VM-***@public.gmane.org>
Sent: Tuesday, July 06, 2010 11:17 PM
Subject: Re: [H390-VM] Re: Fullscreen support for VM/370 Sixpack - UPdate

Post by Mike Stramba
I don't see anything on bitsavers titled either VMCF, or Virtual
Machine Communications Facility, is it documented inside another
manual?

Post by Dave Wade
VMCF exists and works
-----Original Message-----

Of

Post by Mike Stramba

Post by Dave Wade
Rocky
Sent: 06 July 2010 19:54
Subject: RE: [H390-VM] Re: Fullscreen support for VM/370 Sixpack - UPdate
this question seems to have gotten mislaid in all the excitement.
What about the VMCF - wherther its an alternative or not is irrelvant.
Does it exist on our version ot the SIX-PACK

------------------------------------
Yahoo! Groups Links

[Rocky]

Yes Dave -

Its not in the VM/370 system programmers guide thats on Bitsavers, but I
remember well that is was in the SPG for SP/5. I used it a lot.
There is also tons of information about Logical Device support facility
there.

Bad News - is that I searched the net this morning and could not find any
references to any VM/SPxx programmer guides.
Good News - I called the system Programmer at a site I worked at 30 years
ago.He was my "gofer" back then.

He told me that he has still has a couple of cartons of OLD documentation in
storage. And that he is pretty sure that Systems programmer guide -
Functional Characteristics of the 4381 and the old POP are still there,
Stuff from his/ (my old office) space.
Actually he sounded happy to get rid of them and what I don;t take now will
probably get crushed in the near future.

Not sure about what other stuff is there but he invited me to come look
around tomorrow.
I have no room to store manuals so I cant take everything but I will make
exception for SPG and the POP.

If anybody has any special requests let me know and I'll look for them while
I'm browsing.

Anybody have any ideas about what I do with them when I get them --- My
grandchildren are too old to sit them down at the scanner for a whole day
and my great-grandchildren are too young.

ROC


From: H390-VM-***@public.gmane.org [mailto:H390-VM-***@public.gmane.org] On Behalf Of
Dave Wade
Sent: Wednesday, July 07, 2010 09:47
To: H390-VM-***@public.gmane.org
Subject: Re: [H390-VM] Re: Fullscreen support for VM/370 Sixpack - UPdate





Yes, but I don't remember which, its a CP facility so probably Systems
Programmers...

----- Original Message -----
From: "Mike Stramba" <mikestramba-***@public.gmane.org <mailto:mikestramba%40gmail.com>
To: <H390-VM-***@public.gmane.org <mailto:H390-VM%40yahoogroups.com> >
Sent: Tuesday, July 06, 2010 11:17 PM
Subject: Re: [H390-VM] Re: Fullscreen support for VM/370 Sixpack - UPdate

I don't see anything on bitsavers titled either VMCF, or Virtual
Machine Communications Facility, is it documented inside another
manual?

Post by Dave Wade
VMCF exists and works
-----Original Message-----

[mailto:H390-VM-***@public.gmane.org <mailto:H390-VM%40yahoogroups.com> ] On
Behalf
Of

Post by Dave Wade
Rocky
Sent: 06 July 2010 19:54
Subject: RE: [H390-VM] Re: Fullscreen support for VM/370 Sixpack - UPdate
this question seems to have gotten mislaid in all the excitement.
What about the VMCF - wherther its an alternative or not is irrelvant.
Does it exist on our version ot the SIX-PACK

------------------------------------
Yahoo! Groups Links

[Martin Trübner]

Rocky,

I found the right book at bitsavers- problem is that for the VM-books
the numbering cheme "has changed"/"got shifted" and are hard to find by title.

I think I know what book you are looking for--- will have more info
tomorrow.

It has VMCF specifics in it - right?

[Rocky]

Right the Book as I remeber it was:

Virtual Machine ????/sp5 systems programmer's guide

I don't remember what the ??? was -

But I am going there tomorrow in any case to rummage thru the boxes - Maybe
I'll find an old installation tape or something interesting.
Aprrecoate any info

Roc



_____

From: H390-VM-***@public.gmane.org [mailto:H390-VM-***@public.gmane.org] On Behalf Of
Martin Tr?bner
Sent: Wednesday, July 07, 2010 17:48
To: H390-VM-***@public.gmane.org
Subject: Re: [H390-VM] Re: Fullscreen support for VM/370 Sixpack - UPdate




Rocky,

I found the right book at bitsavers- problem is that for the VM-books
the numbering cheme "has changed"/"got shifted" and are hard to find by
title.

I think I know what book you are looking for--- will have more info
tomorrow.

It has VMCF specifics in it - right?

[Dave McGuire]

Post by Rocky
But I am going there tomorrow in any case to rummage thru the boxes - Maybe
I'll find an old installation tape or something interesting.
Aprrecoate any info

Hmm, if you do end up finding any old installation tapes...I've
recently acquired some real 370 iron (ok, only a "baby" 370, a 9375)
that I'm hopefully going to try to fire up soon.

Or if they any 3270-protocol terminals lying around.. =) (hey, a guy
can hope!)

-Dave

[Mike Stramba]

Tony mentoned earlier in the thread the VMCF stuff is in :

http://bitsavers.org/pdf/ibm/370/vm370/GC20-1807-7_VM370syPgm_4-81.pdf

It's also here (and seems to be a better scan (I don't know which
version is more relevant), .. the first few paragraphs I read are
identical )

http://bitsavers.org/pdf/ibm/370/VM_SP/SC19-6203-2_VM_SP_System_Programmers_Guide_Release_3_Aug83.pdf

There is also more SP stuff in :

http://bitsavers.org/pdf/ibm/370/VM_SP/

Post by Dave McGuire

Post by Rocky
But I am going there tomorrow in any case to rummage thru the boxes - Maybe
I'll find an old installation tape or something interesting.
Aprrecoate any info

Hmm, if you do end up finding any old installation tapes...I've
recently acquired some real 370 iron (ok, only a "baby" 370, a 9375)
that I'm hopefully going to try to fire up soon.
Or if they any 3270-protocol terminals lying around.. =) (hey, a guy
can hope!)
-Dave
--
Dave McGuire
Port Charlotte, FL
------------------------------------
Yahoo! Groups Links

[Rocky]

dave -

I am in haifa israel - you are in Fl
not going yo send you an old 3270

But a tape maybe...
More important is the literature


_____

From: H390-VM-***@public.gmane.org [mailto:H390-VM-***@public.gmane.org] On Behalf Of
Dave McGuire
Sent: Wednesday, July 07, 2010 18:16
To: H390-VM-***@public.gmane.org
Subject: Re: [H390-VM] Re: Fullscreen support for VM/370 Sixpack - UPdate

But I am going there tomorrow in any case to rummage thru the boxes -

Maybe

I'll find an old installation tape or something interesting.
Aprrecoate any info

Hmm, if you do end up finding any old installation tapes...I've
recently acquired some real 370 iron (ok, only a "baby" 370, a 9375)
that I'm hopefully going to try to fire up soon.

Or if they any 3270-protocol terminals lying around.. =) (hey, a guy
can hope!)

-Dave

[Dave McGuire]

Post by Rocky
dave -
I am in haifa israel - you are in Fl
not going yo send you an old 3270

Ahh! I didn't know that...Yes, that'd be pretty pricey, shipping a
100lb terminal. :)

Post by Rocky
But a tape maybe...
More important is the literature

The literature is definitely important. The hardware is rapidly
becoming extinct, though. :-( I'd hollow out the interior of my house
for a 3090!

-Dave

[Dave Wade]

http://www.computermuseum.org.uk/

Dave Wade G4UGM
Illegitimi Non Carborundum

Post by Rocky
-----Original Message-----
Sent: 07 July 2010 18:36
Subject: Re: [H390-VM] Re: Fullscreen support for VM/370
Sixpack - UPdate

Post by Rocky
dave -
I am in haifa israel - you are in Fl
not going yo send you an old 3270

Ahh! I didn't know that...Yes, that'd be pretty pricey,
shipping a 100lb terminal. :)

Post by Rocky
But a tape maybe...
More important is the literature

The literature is definitely important. The hardware is
rapidly becoming extinct, though. :-( I'd hollow out the
interior of my house for a 3090!
-Dave
--
Dave McGuire
Port Charlotte, FL
------------------------------------
Yahoo! Groups Links

[Rocky]

I checked out both those links -
Th manual are a lot better than what I foun in in VM/370 and the VMCF
chapters are usable.

Still I seem to remeber tht the one I had (SP/5) had a lot more information.

I already promised to go there (old shop) for lunch tomorrow - to say hello
and rummage so I will go anyway and let you know what Ifind out.
Reminiscing.

They tell me a few of the secretaries are still there. Wonder if they have
changed as much as the hardware and the software.
I of course am exactly the same. + a kilo or two. :-)

Roc



_____

From: H390-VM-***@public.gmane.org [mailto:H390-VM-***@public.gmane.org] On Behalf Of
Dave Wade
Sent: Wednesday, July 07, 2010 20:58
To: H390-VM-***@public.gmane.org
Subject: RE: [H390-VM] Re: Fullscreen support for VM/370 Sixpack - UPdate




http://www.computermuseum.org.uk/

Dave Wade G4UGM
Illegitimi Non Carborundum

Post by Rocky
-----Original Message-----

Behalf Of Dave McGuire

Post by Rocky
Sent: 07 July 2010 18:36
Subject: Re: [H390-VM] Re: Fullscreen support for VM/370
Sixpack - UPdate

dave -
I am in haifa israel - you are in Fl
not going yo send you an old 3270

Ahh! I didn't know that...Yes, that'd be pretty pricey,
shipping a 100lb terminal. :)

But a tape maybe...
More important is the literature

The literature is definitely important. The hardware is
rapidly becoming extinct, though. :-( I'd hollow out the
interior of my house for a 3090!
-Dave
--
Dave McGuire
Port Charlotte, FL
------------------------------------
Yahoo! Groups Links

[Robert O'Hara]

So does anyone have a recording of the sound an 029 keypunch makes when you type a character?

Post by Dave Wade
http://www.computermuseum.org.uk/
Dave Wade G4UGM
Illegitimi Non Carborundum

Post by Rocky
-----Original Message-----
Sent: 07 July 2010 18:36
Subject: Re: [H390-VM] Re: Fullscreen support for VM/370
Sixpack - UPdate

Post by Rocky
dave -
I am in haifa israel - you are in Fl
not going yo send you an old 3270

Ahh! I didn't know that...Yes, that'd be pretty pricey,
shipping a 100lb terminal. :)

Post by Rocky
But a tape maybe...
More important is the literature

The literature is definitely important. The hardware is
rapidly becoming extinct, though. :-( I'd hollow out the
interior of my house for a 3090!
-Dave
--
Dave McGuire
Port Charlotte, FL
------------------------------------
Yahoo! Groups Links

[Rocky]

Is that the one I used back in the days of the 1401 to add the date card to
the deck I got ftrom the keypunch operators.
Or was that 01F

I remember looking into an 088 or 077 while cards were merging and thought
that was the last word in tecnology ever.
But those were the days when only Dick Tracey and Sam Ketchum had a cell
phones. (on their watches).

Maybe I'll find an 01F when I start rummaging this afternoon.
Pretty sure someone has taken that for nostalgia

roc
.


_____

From: H390-VM-***@public.gmane.org [mailto:H390-VM-***@public.gmane.org] On Behalf Of
Robert O'Hara
Sent: Thursday, July 08, 2010 08:14
To: H390-VM-***@public.gmane.org
Subject: [H390-VM] Re: Fullscreen support for VM/370 Sixpack - UPdate




So does anyone have a recording of the sound an 029 keypunch makes when you
type a character?

Post by Dave Wade
http://www.computermuseum.org.uk/
Dave Wade G4UGM
Illegitimi Non Carborundum

Post by Rocky
-----Original Message-----

Behalf Of Dave McGuire

Post by Dave Wade

Post by Rocky
Sent: 07 July 2010 18:36
Subject: Re: [H390-VM] Re: Fullscreen support for VM/370
Sixpack - UPdate

dave -
I am in haifa israel - you are in Fl
not going yo send you an old 3270

Ahh! I didn't know that...Yes, that'd be pretty pricey,
shipping a 100lb terminal. :)

But a tape maybe...
More important is the literature

The literature is definitely important. The hardware is
rapidly becoming extinct, though. :-( I'd hollow out the
interior of my house for a 3090!
-Dave
--
Dave McGuire
Port Charlotte, FL
------------------------------------
Yahoo! Groups Links

[Rocky]

Hi all,

I have returned from my rumagging expedition.
As far as tapes etc. Non-existent.
All they have are some DDR volumes of the entire system from back around
1995 which they transferred to casettes.

About documentatiion I was more successful.

They have the entire 24 volume set of VM/SP5

As well as some other stuff.
All the data areas etc. etc;etc;

I have no room for all of it so I took only the five volumes that interested
me.

But it will still be there at for another two weeks if somebody wants me to
go back.
My system programmer friend is retiring at the end of the month, so hurry if
you are interested, because I won't have any contacts after that.

What I took is;

IBM VITUAL MACHINE/SYSTEM PRODUCT - System programmer's guide sc19-6203-0
first edition september 1980.Still has some pencilled in notations that I
made.


IBM sytem 370 Principles of Operation ga22-700-8 ninth edition October 1981
- Might be availble on the net - but this a good one - The low core
desriptions are very coomplete

DSF release 14 GC35-00330-18 seventeenth edition June 1992.

System Product Editor command and MACRO Reference (XEDIT) Release 5
SC24-5221-4 (well that might be of use for development stuff)

And the crowning Glory

VM/SP INSTALLATION GUIDE RELEASE 5 SC24-5237-3 December 1986 (also has a
TNL from december 1988)

If anybody is interested in any of this let me know.
Roc
________________________________

From: H390-VM-***@public.gmane.org [mailto:H390-VM-***@public.gmane.org] On
Behalf Of Robert O'Hara
Sent: Thursday, July 08, 2010 08:14
To: H390-VM-***@public.gmane.org
Subject: [H390-VM] Re: Fullscreen support for VM/370 Sixpack -
UPdate




So does anyone have a recording of the sound an 029 keypunch makes
when you type a character?

Post by Dave Wade
http://www.computermuseum.org.uk/
Dave Wade G4UGM
Illegitimi Non Carborundum

Post by Rocky
-----Original Message-----

<mailto:H390-VM%40yahoogroups.com> ] On Behalf Of Dave McGuire

Post by Dave Wade

Post by Rocky
Sent: 07 July 2010 18:36
Subject: Re: [H390-VM] Re: Fullscreen support for VM/370
Sixpack - UPdate

dave -
I am in haifa israel - you are in Fl
not going yo send you an old 3270

Ahh! I didn't know that...Yes, that'd be pretty pricey,
shipping a 100lb terminal. :)

But a tape maybe...
More important is the literature

The literature is definitely important. The hardware is
rapidly becoming extinct, though. :-( I'd hollow out the
interior of my house for a 3090!
-Dave
--
Dave McGuire
Port Charlotte, FL
------------------------------------
Yahoo! Groups Links

[Dave Wade]

I have some .......
... but in the UK.....



Dave Wade G4UGM

Illegitimi Non Carborundum



-----Original Message-----
From: H390-VM-***@public.gmane.org [mailto:H390-VM-***@public.gmane.org] On Behalf Of
Rocky
Sent: 07 July 2010 18:26
To: H390-VM-***@public.gmane.org
Subject: RE: [H390-VM] Re: Fullscreen support for VM/370 Sixpack - UPdate




dave -

I am in haifa israel - you are in Fl
not going yo send you an old 3270

But a tape maybe...
More important is the literature


_____

From: H390-VM-***@public.gmane.org [mailto:H390-VM-***@public.gmane.org] On Behalf Of
Dave McGuire
Sent: Wednesday, July 07, 2010 18:16
To: H390-VM-***@public.gmane.org
Subject: Re: [H390-VM] Re: Fullscreen support for VM/370 Sixpack - UPdate

But I am going there tomorrow in any case to rummage thru the boxes -

Maybe

I'll find an old installation tape or something interesting.
Aprrecoate any info

Hmm, if you do end up finding any old installation tapes...I've
recently acquired some real 370 iron (ok, only a "baby" 370, a 9375)
that I'm hopefully going to try to fire up soon.

Or if they any 3270-protocol terminals lying around.. =) (hey, a guy
can hope!)

-Dave

[gm1mqe]

Dave, I tried to Email you without success, can you drop me an email at gm1mqe-5uyhOP+***@public.gmane.org

Andy

[Dave McGuire]

Which Dave?

-Dave

[Dave Wade]

Thats very odd. I have

GC20-1807-7_VM370syPgm_4-81.pdf

which I am sure I got from bitsavers and on page 143 there is a chapter
"Using the Virtual Machine Communication Facility"

Dave Wade G4UGM
Illegitimi Non Carborundum



-----Original Message-----
From: H390-VM-***@public.gmane.org [mailto:H390-VM-***@public.gmane.org] On Behalf Of
Rocky
Sent: 07 July 2010 15:38
To: H390-VM-***@public.gmane.org
Subject: RE: [H390-VM] Re: Fullscreen support for VM/370 Sixpack - UPdate




Yes Dave -

Its not in the VM/370 system programmers guide thats on Bitsavers, but I
remember well that is was in the SPG for SP/5. I used it a lot.
There is also tons of information about Logical Device support facility
there.

Bad News - is that I searched the net this morning and could not find any
references to any VM/SPxx programmer guides.
Good News - I called the system Programmer at a site I worked at 30 years
ago.He was my "gofer" back then.

He told me that he has still has a couple of cartons of OLD documentation in
storage. And that he is pretty sure that Systems programmer guide -
Functional Characteristics of the 4381 and the old POP are still there,
Stuff from his/ (my old office) space.
Actually he sounded happy to get rid of them and what I don;t take now will
probably get crushed in the near future.

Not sure about what other stuff is there but he invited me to come look
around tomorrow.
I have no room to store manuals so I cant take everything but I will make
exception for SPG and the POP.

If anybody has any special requests let me know and I'll look for them while
I'm browsing.

Anybody have any ideas about what I do with them when I get them --- My
grandchildren are too old to sit them down at the scanner for a whole day
and my great-grandchildren are too young.

ROC


From: H390-VM-***@public.gmane.org [mailto:H390-VM-***@public.gmane.org] On Behalf Of
Dave Wade
Sent: Wednesday, July 07, 2010 09:47
To: H390-VM-***@public.gmane.org
Subject: Re: [H390-VM] Re: Fullscreen support for VM/370 Sixpack - UPdate





Yes, but I don't remember which, its a CP facility so probably Systems
Programmers...

----- Original Message -----
From: "Mike Stramba" <mikestramba-***@public.gmane.org <mailto:mikestramba%40gmail.com>
To: <H390-VM-***@public.gmane.org <mailto:H390-VM%40yahoogroups.com> >
Sent: Tuesday, July 06, 2010 11:17 PM
Subject: Re: [H390-VM] Re: Fullscreen support for VM/370 Sixpack - UPdate

I don't see anything on bitsavers titled either VMCF, or Virtual
Machine Communications Facility, is it documented inside another
manual?

Post by Dave Wade
VMCF exists and works
-----Original Message-----

[mailto:H390-VM-***@public.gmane.org <mailto:H390-VM%40yahoogroups.com> ] On
Behalf
Of

Post by Dave Wade
Rocky
Sent: 06 July 2010 19:54
Subject: RE: [H390-VM] Re: Fullscreen support for VM/370 Sixpack - UPdate
this question seems to have gotten mislaid in all the excitement.
What about the VMCF - wherther its an alternative or not is irrelvant.
Does it exist on our version ot the SIX-PACK

------------------------------------
Yahoo! Groups Links

[Rocky]

If you read the original suggestion carefully


Option A - was to do a read access only and then just copy the file (not a
big risk) - File was returned via the reader
Option B was to have a VMCF connection - so only one program accessing the
disk - the front end in the users machine
Option C -was to have the dial program working in the users machine so need
for access at all.

For option A as I unerstood andy's letter was saying that weI can do the
link and access without a PW.
The application is not always linked but can do the LINK RR or to the
users disk from the main machine without a password.
Will always have to do an access immediatley before reading the file. Then
we can release
not much risk there .

Not sure that it would work but if it does what is the difference -
the SIO is to the virtual address what difference would it make.
You would still need two sessions to your machine

Anyway Options B or C seem more intersting to me.
Whats your opinion about those.

For your emulator to connect to hercules you would have to use the LU-Name
function - Not all the emulators support that.
Then you need two pyiscal sessions. One terminal connected to your 009 an
another one connected to your 2C2

Since we only need two logical sessions and not two physical sessions dial
can handle that very easily.

The ENA and DISABLE seems more comlicated and cumbersome than the other
ideas

Roc

_____

From: H390-VM-***@public.gmane.org [mailto:H390-VM-***@public.gmane.org] On Behalf Of
Robert O'Hara
Sent: Tuesday, July 06, 2010 19:17
To: H390-VM-***@public.gmane.org
Subject: [H390-VM] Re: Fullscreen support for VM/370 Sixpack - UPdate




Wait! Wait! Don't do it yet!

A couple of points. First of all, having two virtual machines linked
read/write to the same minidisk is a recipe for disaster. The files on the
disk will become scrambled and the contents destroyed. I can explain this
problem in WAY more detail if you are interested.

Secondly, I'm not convinced that the fullscreen editor needs to run in a
separate virtual machine. As was already demonstrated earlier in this
thread, it is possible from a CMS user's machine (with appropriate CP
priviledges) to
1. Disable an "extra" 3270 terminal at a specific address
CP DISABLE 2C2
2. Attach the terminal to the current virtual machine
CP ATTACH 2C2 TO MAINT AS 2C2
3. Enable the terminal
CP ENABLE 2C2
At this point, I believe that a CMS program (an editor, for example) could
then to SIOs to that attached device.

Thus the full screen editor is just another CMS program. It just happens to
address the second screen attached to the user's machine. So you would use
your "main" terminal to issue commands, and when you issued the new editor
command, the second terminal would light up and you would switch to it to
edit the file.

Thus there is no need for a separate virtual machine to be running. This is
all just a simple matter of 370 and 3270 I/O programming.

Or am I missing something???

Bob

Post by Rocky
That sounds great - Actually my approach was that the user logons on to the
the dial application with his real USER-ID and Password.
Which I compare to the VM directory or a copy of the vm directroy which the
DIAL machine has access to.
then Detach --- But that is moot if we use option "C".
If we stick with option "A" I Like your approach better.
Lets see what the consensus is
Roc
_____

[mailto:H390-VM-***@public.gmane.org <mailto:H390-VM%40yahoogroups.com> ] On
Behalf Of

Post by Rocky
gm1mqe
Sent: Tuesday, July 06, 2010 16:55
Subject: [H390-VM] Re: Fullscreen support for VM/370 Sixpack - UPdate
In the VM system at Greenock I zapped CP code to allow a special user (We
used class H) to be able to link ANY minidisk with a master password, rather
three read write and multi. These passwords were hard coded but changed at
times via an edit the nuc build. This was used for some security stuff I
dont want to talk about! If we allowed the edit user ID to use this it can
get access to any cms disk. Not sure how we would ensure that only the owner
can access the disks but it could be done I am sure. Perhaps in our
"hobbist" user it would not matter to protect access?
Andy

[Ivan Warren]

Post by Rocky
Since we only need two logical sessions and not two physical
sessions dial can handle that very easily.
The ENA and DISABLE seems more comlicated and cumbersome than the other
ideas

To me, the idea was always this (barring Fullscreen DIAG 58 I/O) :

A Dialed terminal to perform FILEL/FLIST and Edition
The 3215 console to do utility tasks.. (assemble, compile.. run..)

All that is needed is to switch from 1 terminal to the other (in the
good ole days, this meant 2 terminals.. IN the mid 80's, you could
already do that with a single terminal - provided you had a sufficiently
new 3x74.. Today, it's standard - it's just yet another window).

So personally, to me, it's a no brainer..

--Ivan

[Rocky]

Ivan

Don’t really follow your logic here.
Please explain -

If we are running an appication in a machine - either a dial application or
diag application effectively the user consol is not available to do other
stuff

The machine is not multi processing anything form the 3215 console unless
the application is talking to it or CP commands from ATT..

So if you start the dial application and then the application automatically
disconnects the console you will get the VM screen
Then dial back to your user id in full screen. When you drop from Dial
application you can logon to your disconnected machine.

If you use two terminals - (and if it works) you will accomlpish essentially
the same result. No advantage other than the dial

But you will have to use the emulator functions to get to the specific
hardware address in hercules. And then the VARY online.
Maybe you can dedicate the terminals like in MVS. How woud these devices be
defined in DMKRIO?

I still think that dial is easier and a more common approach for the user.
Also very standard.
But I believe it will be transparent and makes no difference to the
program. Still SIO to a virtual address.
Correct me if I am wrong


BTW - the way the application is written you can logon with 3 terminals and
each be doing a different funtion or each editing a different file
But that would be the same with either approach. Actually it should work
with a combination of both approaches.
Don’t see that it would matter to the application at all if the devices are
virtual defines grafs or attached devices.

But you can correct me if I am missing something.

Roc

-----Original Message-----
From: H390-VM-***@public.gmane.org [mailto:H390-VM-***@public.gmane.org] On Behalf Of
Ivan Warren
Sent: Tuesday, July 06, 2010 20:18
To: H390-VM-***@public.gmane.org
Subject: Re: [H390-VM] Re: Fullscreen support for VM/370 Sixpack - UPdate

Post by Rocky
Since we only need two logical sessions and not two physical sessions
dial can handle that very easily.
The ENA and DISABLE seems more comlicated and cumbersome than the
other ideas

To me, the idea was always this (barring Fullscreen DIAG 58 I/O) :

A Dialed terminal to perform FILEL/FLIST and Edition The 3215 console to do
utility tasks.. (assemble, compile.. run..)

All that is needed is to switch from 1 terminal to the other (in the good
ole days, this meant 2 terminals.. IN the mid 80's, you could already do
that with a single terminal - provided you had a sufficiently new 3x74..
Today, it's standard - it's just yet another window).

So personally, to me, it's a no brainer..

--Ivan

[Ivan Warren]

Post by Rocky
Ivan
Don’t really follow your logic here.
Please explain -
If we are running an appication in a machine - either a dial application or
diag application effectively the user consol is not available to do other
stuff

Effectivelly, you are in a virtual machine (that is, the complete
replicate of an entire system) - you can do whatever you want!

Post by Rocky
The machine is not multi processing anything form the 3215 console unless
the application is talking to it or CP commands from ATT..

Even if your operating system doesn't allow multi tasking, you can do
"multileaving" - that is - service more than 1 terminal (in the TP
sense) with a single task..

Post by Rocky
So if you start the dial application and then the application automatically
disconnects the console you will get the VM screen
Then dial back to your user id in full screen. When you drop from Dial
application you can logon to your disconnected machine.

That'd certainly be quite complicated to do - yet feasible.. But -
nowadays, having more than 1 terminal session on a single screen is
trivial (as I said : in 1987 or so, I could even do this with a 3174)..
so why make it complicated ?

Post by Rocky
If you use two terminals - (and if it works) you will accomlpish essentially
the same result. No advantage other than the dial

You can use the switching capability of the terminal from which you are
connecting from.. Assuming you have a multi windowing system (Windows,
X11 or Whatnot) you should be able to have more than 1 terminal open
simultaneously.

Post by Rocky
But you will have to use the emulator functions to get to the specific
hardware address in hercules. And then the VARY online.
Maybe you can dedicate the terminals like in MVS. How woud these devices be
defined in DMKRIO?

To DMKRIO, All that is known is a device Address.. Those device
addresses can be define in hercules (pretty much the same way they can
be defined on an ICC on a z/Arch machine) - that is : a device address
is just a port to a terminal.. The advantage of DIAL here is that you
can manually connect to a virtual machine's 3270 defined terminal device.

Post by Rocky
I still think that dial is easier and a more common approach for the user.
Also very standard.
But I believe it will be transparent and makes no difference to the
program. Still SIO to a virtual address.
Correct me if I am wrong

Wait wait wait.. You ALWAYS issue SIO to an address.. Whether it's
virtual or real is only controled by the underlying hypervisor.. The
important fact that SIO is privileged allows the hypervisor to redirect
any I/O request from a virtual address to a real address (in the mean
time - it will translate virtual storage addresses to real addresses and
virtual device addresses to real addresses.. And if the SIO is to a an
MDISK, it will also translate cylinder numbers).

On a real machine :
SIO X'400' -> Goes to real address X'400'
In a virtual machine
SIO X'400' -> Goes to whatever is defined as X'400' in the virtual machine

If the virtual machine has a 'DEFINE GRAF 400' but *real* device X'600'
*dials* to the virtual machine, then all I/O directed to X'400' goes to
real device X'600'.. These are "Virtual machines" - Virtualization smoke
of screen !

Post by Rocky
BTW - the way the application is written you can logon with 3 terminals and
each be doing a different funtion or each editing a different file
But that would be the same with either approach. Actually it should work
with a combination of both approaches.
Don’t see that it would matter to the application at all if the devices are
virtual defines grafs or attached devices.

The 'LOGIN' function is to allow any terminal to connect to a virtual
machine.. One you have logged in, the hypervisor will treat your
terminal as the type of terminal defined for the virtual machine (3215
being the only option in VM/370). Not only do you get the virtual
machine console 3215 defined device - but also the Manual Controls (See
the POO for the definition of Manual Controls).

A DIALed terminal is just a way to dynamically attach a 3270 terminal to
a virtual machine.

Post by Rocky
But you can correct me if I am missing something.

VM isn't trivial.. don't fret ! and if I may seem brutal sometimes - you
just have to assume it's just me (not you) - ask your question again -
and I'll just reformulate..

Take care!

--Ivan

[Thomas Kern]

I like a variation of Option A, call it A2.

A service machine that owns a number of minidisks, No passwords. Each minidisk contains a
project or a subset of a project. The users dial to the SVM, identified/authenticates
themselves, specifies the project and file that they want to edit. The SVM supervisor code
accesses the project minidisk containing the file, reads it into memory and presents it
to the users for editing (that is where your fullscreen SIO code comes in). Because there
are no passwords, the access process only needs to worry about the backup/restore
superuser (if you have one). If you want to include a process to extract/insert a file
into this library SVM, you can use VMCF SENDX to trigger a file transfer or SEND/RECV to
actually do the transfer.

Post by Rocky
If you read the original suggestion carefully
Option A - was to do a read access only and then just copy the file (not
a big risk) - File was returned via the reader
Option B was to have a VMCF connection - so only one program accessing
the disk - the front end in the users machine
Option C -was to have the dial program working in the users machine so
need for access at all.
For option A as I unerstood andy's letter was saying that weI can do the
link and access without a PW.
The application is not always linked but can do the LINK RR or to the
users disk from the main machine without a password.
Will always have to do an access immediatley before reading the file.
Then we can release
not much risk there .

...SNIPPED...

[Rocky]

Hi Thomas:

It's a new day for me.
Whew - reading all that political stuff made real tired yesterday: Glad that
you are addressing the main issue,

Like your suggestion:

Your point is well taken - That was close to my original idea - A service
machine - Something similar to a mini CICS -
Multi-user - Multi-application Machine with pseudo multi-tasking, and full
screen 3270 I/O.

Edit/Flist etc. was just one aplication. The Idea was to build the machine
so that it could support severeal transactions and multi users.
simultaneously,

However the discussion got side-tracked, and when everybody starts arguing
the real questions get lost.

What did come out of all the discussion was:


That specifically for the EDIT/FLIST transaction it might be more
convenient for the programmers to use a different approach?.
The local machine has a second terminal (either define graf or the
attach device) and that the programmer when he wants to enter EDIT mode can
start in his own local machine a program that will talk with the second
device -

His original Console is more or less useless at this point but he
switches to the emulators second session and does the edit - when he is
finished, the program ends and control is back on the original Console
That solution is a lot simpler to build since we only have to worry
about writing the actual edit routines and dont need the Pseudo
Multi-tasking environment



Looks like we are talking about two separate environments here.


Option "A" for application development
Option "C" for the edit tool


Unless someone else comes up with a better suggestion, that is probably what
I will attempt to do:
Two separate programs - or probably one program that can perform both
functionalities.

From the techincal questions that were answered between all the bickering
I see that the consensus is:


SIO routines and the 3270 part of the program is the same for both
methods DIAL AND ATTACH.
VMCF is an option FOR INTER MACHINE COMMUNICATION.
From the systems Gurus - we all aggree that a Diagnose 58 or LDEV
solution to VM/370 is not going to happen in the near future



Thomas; Thanks for the input.

All; thanks for the replys, which almost got lost in the politics

If any one is interested in seeing the first two screens of the test VIA
dial I can give you the logon information off line.

I am not familiar with VM/370 so it will take me some time to fix the Query
issue - where Mike crashed my machine
Stay away from that if you logo on.

Roc


________________________________


From: H390-VM-***@public.gmane.org [mailto:H390-VM-***@public.gmane.org] On
Behalf Of Thomas Kern
Sent: Wednesday, July 07, 2010 06:01
To: H390-VM-***@public.gmane.org
Subject: Re: [H390-VM] Re: Fullscreen support for VM/370 Sixpack -
UPdate




I like a variation of Option A, call it A2.

A service machine that owns a number of minidisks, No passwords.
Each minidisk contains a
project or a subset of a project. The users dial to the SVM,
identified/authenticates
themselves, specifies the project and file that they want to edit.
The SVM supervisor code
accesses the project minidisk containing the file, reads it into
memory and presents it
to the users for editing (that is where your fullscreen SIO code
comes in). Because there
are no passwords, the access process only needs to worry about the
backup/restore
superuser (if you have one). If you want to include a process to
extract/insert a file
into this library SVM, you can use VMCF SENDX to trigger a file
transfer or SEND/RECV to
actually do the transfer.



Reply to sender <mailto:tlk_sysprog-/***@public.gmane.org?subject=Re: [H390-VM]
Re: Fullscreen support for VM/370 Sixpack - UPdate> | Reply to group
<mailto:H390-VM-***@public.gmane.org?subject=Re: [H390-VM] Re: Fullscreen support
for VM/370 Sixpack - UPdate> | Reply via web post
<http://groups.yahoo.com/group/H390-VM/post;_ylc=X3oDMTJwaXM2YXRyBF9TAzk3MzU
5NzE0BGdycElkAzI1Mzk5MjcEZ3Jwc3BJZAMxNzA1MDUzODAwBG1zZ0lkAzczMTAEc2VjA2Z0cgR
zbGsDcnBseQRzdGltZQMxMjc4NDcxNjYx?act=reply&messageNum=7310> | Start a New
Topic
<http://groups.yahoo.com/group/H390-VM/post;_ylc=X3oDMTJlM2Q4dHU5BF9TAzk3MzU
5NzE0BGdycElkAzI1Mzk5MjcEZ3Jwc3BJZAMxNzA1MDUzODAwBHNlYwNmdHIEc2xrA250cGMEc3R
pbWUDMTI3ODQ3MTY2MQ-->
Messages in this topic
<http://groups.yahoo.com/group/H390-VM/message/7213;_ylc=X3oDMTM0NGdtOGU2BF9
TAzk3MzU5NzE0BGdycElkAzI1Mzk5MjcEZ3Jwc3BJZAMxNzA1MDUzODAwBG1zZ0lkAzczMTAEc2V
jA2Z0cgRzbGsDdnRwYwRzdGltZQMxMjc4NDcxNjYxBHRwY0lkAzcyMTM-> (63)
Recent Activity:

* New Members
<http://groups.yahoo.com/group/H390-VM/members;_ylc=X3oDMTJmcWdtdjN0BF9TAzk3
MzU5NzE0BGdycElkAzI1Mzk5MjcEZ3Jwc3BJZAMxNzA1MDUzODAwBHNlYwN2dGwEc2xrA3ZtYnJz
BHN0aW1lAzEyNzg0NzE2NjE-?o=6> 4

Visit Your Group
<http://groups.yahoo.com/group/H390-VM;_ylc=X3oDMTJlaHRnc3AwBF9TAzk3MzU5NzE0
BGdycElkAzI1Mzk5MjcEZ3Jwc3BJZAMxNzA1MDUzODAwBHNlYwN2dGwEc2xrA3ZnaHAEc3RpbWUD
MTI3ODQ3MTY2MQ-->
Yahoo! Groups
<http://groups.yahoo.com/;_ylc=X3oDMTJkM2llajh0BF9TAzk3MzU5NzE0BGdycElkAzI1M
zk5MjcEZ3Jwc3BJZAMxNzA1MDUzODAwBHNlYwNmdHIEc2xrA2dmcARzdGltZQMxMjc4NDcxNjYx>

Switch to: Text-Only
<mailto:H390-VM-traditional-***@public.gmane.org?subject=Change Delivery Format:
Traditional> , Daily Digest
<mailto:H390-VM-digest-***@public.gmane.org?subject=Email Delivery: Digest> *
Unsubscribe <mailto:H390-VM-unsubscribe-***@public.gmane.org?subject=Unsubscribe>
* Terms of Use <http://docs.yahoo.com/info/terms/>
.

<http://geo.yahoo.com/serv?s=97359714/grpId=2539927/grpspId=1705053800/msgId
=7310/stime=1278471661/nc1=1/nc2=2/nc3=3>

[Harold Grovesteen]

Yes, I have been somewhat confused by the need for a separate machine to
do this. You don't even need a DIAL approach if you are willing to have
two emulator connections, one for the VM console interface and a second
which is a 3270 driven from the user's virtual machine for full screen
applications. MVS configurations have this requirement, a 3270 for the
system console and a 3270 for TSO usage.

I don't know if the I/O interrupt handling within CMS is a challenge or
not.

As far as the simple API, a user provided DIAGNOSE similar to 58 could
be developed for this purpose. That would separate the complexities of
managing the CP / VM usage of the full screen. Just a suggestion. Not
really knowledgable enough to know the pros and cons to this approach.

The separate machine approach might still be worth while for a CICS
look-alike program. It does have some value.

Harold Grovesteen

Post by Robert O'Hara
Wait! Wait! Don't do it yet!
A couple of points. First of all, having two virtual machines linked read/write to the same minidisk is a recipe for disaster. The files on the disk will become scrambled and the contents destroyed. I can explain this problem in WAY more detail if you are interested.
Secondly, I'm not convinced that the fullscreen editor needs to run in a separate virtual machine. As was already demonstrated earlier in this thread, it is possible from a CMS user's machine (with appropriate CP priviledges) to
1. Disable an "extra" 3270 terminal at a specific address
CP DISABLE 2C2
2. Attach the terminal to the current virtual machine
CP ATTACH 2C2 TO MAINT AS 2C2
3. Enable the terminal
CP ENABLE 2C2
At this point, I believe that a CMS program (an editor, for example) could then to SIOs to that attached device.
Thus the full screen editor is just another CMS program. It just happens to address the second screen attached to the user's machine. So you would use your "main" terminal to issue commands, and when you issued the new editor command, the second terminal would light up and you would switch to it to edit the file.
Thus there is no need for a separate virtual machine to be running. This is all just a simple matter of 370 and 3270 I/O programming.
Or am I missing something???
Bob

Post by Rocky
That sounds great - Actually my approach was that the user logons on to the
the dial application with his real USER-ID and Password.
Which I compare to the VM directory or a copy of the vm directroy which the
DIAL machine has access to.
then Detach --- But that is moot if we use option "C".
If we stick with option "A" I Like your approach better.
Lets see what the consensus is
Roc
_____
gm1mqe
Sent: Tuesday, July 06, 2010 16:55
Subject: [H390-VM] Re: Fullscreen support for VM/370 Sixpack - UPdate
In the VM system at Greenock I zapped CP code to allow a special user (We
used class H) to be able to link ANY minidisk with a master password, rather
three read write and multi. These passwords were hard coded but changed at
times via an edit the nuc build. This was used for some security stuff I
dont want to talk about! If we allowed the edit user ID to use this it can
get access to any cms disk. Not sure how we would ensure that only the owner
can access the disks but it could be done I am sure. Perhaps in our
"hobbist" user it would not matter to protect access?
Andy

------------------------------------
Yahoo! Groups Links

[kerravon86]

Post by Harold Grovesteen
As far as the simple API, a user provided DIAGNOSE
similar to 58 could be developed for this purpose.

Ah - excellent. Roc, why not write the API in C,
as per DIAG 58 specs. All just in normal user
space. GCC will generate assembler that has no
dependencies on anything other than a larger
than normal R13.

The C code can then potentially be moved to
an unspecified version of Hercules, inshallah.

BFN. Paul.

[kerravon86]

Post by kerravon86
The C code can then potentially be moved to
an unspecified version of Hercules, inshallah.

Or CP, inshallah**2.

BFN. Paul.

[kerravon86]

Post by Adam Thornton
Here's my operational definition.
"compatible" means, doesn't make life worse or impossible for any
operating system for the documented architecture.

I think some/most programmers have a more important
level of compatibility - it's how their apps behave
under the OS running under the architecture under
the emulator.

When compared with a later version of the OS under
real iron.

Post by Adam Thornton
That is, if your changes break VM, they are not compatible.

And a second point is whether any particular
behaviour can be switched off via an option.
If it can, any disadvantage, real or theoretical,
is a moot point.

BFN. Paul.

[Adam Thornton]

Post by kerravon86

Post by Adam Thornton
Here's my operational definition.
"compatible" means, doesn't make life worse or impossible for any
operating system for the documented architecture.

I think some/most programmers have a more important
level of compatibility - it's how their apps behave
under the OS running under the architecture under
the emulator.
When compared with a later version of the OS under
real iron.

I think you are absolutely, completely wrong there. That is not "compatibility". That is an added feature which is, by its very nature, incompatible with the actual goal of emulation. It may be convenient for you. It is not compatible with the goal of accurate emulation.

Post by kerravon86

Post by Adam Thornton
That is, if your changes break VM, they are not compatible.

And a second point is whether any particular
behaviour can be switched off via an option.
If it can, any disadvantage, real or theoretical,
is a moot point.

No, no it is not.

Now, I will concede that if your new compatibility-breaking features can be switched ON with an option, and if that option is not present, then software that actually depends on the emulator continuing to work like it always has, which is also how it is documented to behave in the Principles of Operation, never knows the difference, then that is not horrible, just irritating.

And it's irritating because *I*, and I think Roger Bowler, and some not-inconsiderable fraction of the users of Hercules expect it to be a System/370, System/390, and zSeries emulator. You appear to want it to be some sort of hybrid MVS simulator thingy. The two things are not the same, and I frankly resent its being steered away from being an emulator, which is actually useful to me (and what the project has historically been), as I have a good deal of interest in the z/VM, z/Linux, and z/OpenSolaris worlds, towards an MVS simulator that provides some sort of future-architecture-accomodation-mode or something, which is completely useless to me.

The thing is, of course, the architecture has a well-defined mechanism for extending it. That's how DIAG works. Your problem is that you would have to rewrite applications--some of which you don't have the source for--to exploit these new DIAGs. Rather than do that, you consider it acceptable to break the program for everyone else in order to accommodate your existing software. I don't like that approach.

I also know that arguing with you is like arguing with a wall, and I don't know why I'm bothering.

Adam

[rocsystems]

Post by Adam Thornton
I also know that arguing with you is like arguing with a wall, and I don't know why I'm bothering.
Adam

HURRAH!

Wish he would say somethig positive once in a while.
Knew a lot of managers like him that had just enough technical know how to be annoying.

I may be wrong,
Perhaps he will volunteer to FIX CP or at least show us where the onle line miracle FIX is

[kerravon86]

Post by rocsystems
HURRAH!
Wish he would say somethig positive once in a while.

You mean something positive like "that's not
impossible, it can be done, watch how I get
this 31-bit program to run under the free
VM we have available"? Or something positive
like "Here's a new version of BREXX. Oh, and
miniunz too. Oh, did I mention BWBASIC. There's
a few more, but I lost track".

Post by rocsystems
Knew a lot of managers like him that had just
enough technical know how to be annoying.

And I still know of a lot of people who get
very pissed off when everything doesn't go
their way. They resort to things like specious
and fallacious arguments. Anything other than
admit it might be them with the problem.

Post by rocsystems
I may be wrong,

You'll always be wrong when you only see what you
want to see.

Post by rocsystems
Perhaps he will volunteer to FIX CP or at least
show us where the one line miracle FIX is

More specious arguments. I never claimed CP
was broken, never said there was a miracle
one-line fix for something that isn't even
broken.

But hey, don't let anything like facts get in
the way of a good story.

And if you weren't blind and dishonest, you might
have noticed that I volunteered to do a hell of
a lot of other stuff.

I don't volunteer to do it for the likes of you
though. There are those who understand and
appreciate it.

And while I don't actually know who you are or
what you've personally contributed to anything,
I assume you've contributed something somewhere,
and unlike you, I appreciate whatever it is that
you have done for the community, irrespective
of the strange desire you seem to have to take
a swipe at someone, for no perceivable (to me)
benefit to yourself.

BFN. Paul.

[kerravon86]

Post by kerravon86
And while I don't actually know who you are or

Sorry, I think I do know who you are, and I
took that the wrong way. Some of your messages
have a name against them, and some of them
don't.

Regardless, the sentiments expressed can be
an addendum to the original, rather than going
to waste.

Apologies again, assuming I took it the wrong way.
I get so many of these things from wannabe
dictators trying to hide behind Godwin when
they've been caught with their pants down, I just
instinctively reply to them.

BFN. Paul.

[Adam Thornton (FSF)]

Post by kerravon86
I get so many of these things from wannabe
dictators trying to hide behind Godwin when
they've been caught with their pants down, I just
instinctively reply to them.

Hey, you know, if you didn't call people Nazis because they disagreed with
you, then maybe they wouldn't have Godwin's law to hide behind.

Just saying.

I'll also point out, for the record, that it's perfectly possible to run
z/VM entirely legally under Hercules with no special dispensation required,
as long as you're running it under Linux on the machine you've got z/VM
licensed for. If you search the archives you'll find me discussing having
done just this. Yes, of course it's slow. But it's a very good way to
make sure that Hercules is actually functional with modern releases. I do
not appreciate your insinuations that I am not merely a Nazi but a Nazi
pirate. Although if I have to pick one, I guess I'd rather be called a
software pirate than a Nazi.

If it's so important to you that your changes go in, whether or not they
reflect community consensus, you are aware that the option of forking the
project exists, right? That's one of the glorious things about open-source
licenses. If your vision of the project does not match other visions,
great, you can take the code and go do your own thing with it, taking
whichever developers believe in your vision with you. I still believe that
consensus is on my side--that is, the primary goal of the Hercules project
is accurate emulation of the architecture.

Adam

[kerravon86]

Post by Adam Thornton (FSF)

Post by kerravon86
I get so many of these things from wannabe
dictators trying to hide behind Godwin when
they've been caught with their pants down, I just
instinctively reply to them.

Hey, you know, if you didn't call people Nazis because
they disagreed with
you, then maybe they wouldn't have Godwin's law to hide behind.

Um, it's not just a disagreement, it's an attempt
to tell me what I can or can't do on my own
computer. What name would you prefer instead of
Nazi?

Post by Adam Thornton (FSF)
Just saying.

Just asking.

Post by Adam Thornton (FSF)
I'll also point out, for the record, that it's perfectly
possible to run
z/VM entirely legally under Hercules with no special
dispensation required,
as long as you're running it under Linux on the machine
you've got z/VM licensed for.

And where do you get the z/VM licence from?

Post by Adam Thornton (FSF)
I do not appreciate your insinuations that I am
not merely a Nazi but a Nazi pirate.

I don't appreciate a lot of your direct statements,
nevermind insinuations.

Over time, I think I will learn to live with it.

But right at the moment, I've still got the shakes.
And nausea too.

Post by Adam Thornton (FSF)
If it's so important to you that your changes go in,

Pardon? "so important"? When did I say something
was so important? And what changes? I haven't
made any so far.

Post by Adam Thornton (FSF)
whether or not they reflect community consensus,

There is no consensus no matter which way you go.

Post by Adam Thornton (FSF)
you are aware that the
option of forking the project exists, right?

Hey genius. What the hell do you think Herc/380
is if it isn't a fork?

Post by Adam Thornton (FSF)
That's one of the glorious things about open-source
licenses. If your vision of the project does not
match other visions,
great, you can take the code and go do your own
thing with it

I thought I just did?

Post by Adam Thornton (FSF)
taking whichever developers believe in your vision with you.

To do what? I've already done it.

Post by Adam Thornton (FSF)
I still believe that consensus is on my side

That's the difference between science and losers.
Losers just make up any old crap and start believing
it.

Scientists are very wary about making statements
like that without a statistically valid poll.

They'll also point out the bleeding obvious -
that even if you have poll results a certain
way - so what? Doesn't mean the alternative
use is useless. There's a place even for Macs
in the world. Why are you using Linux instead
of the decade-long industry standard Windows
anyway?

Post by Adam Thornton (FSF)
that is, the primary goal of the Hercules project
is accurate emulation of the architecture.

Yada yada yada. And? Is someone interfering
with that? If so, who, when, where, why? I
know that I personally have contributed fixes
to Hercules. Spent an entire weekend tracking
down some sort of socket problem.

I don't know you from a bar of soap, so for all
I know, you may be a Hercules developer. If so,
thanks for your hard work. If not, Mr Soap, what
have you contributed to Hercules, or anything
much of anything, recently? I'm standing by
ready to thank you for it, regardless of your
dictatorial tendencies. I would have formed a
temporary alliance with a cruel dictator like
Stalin too, and I'm sure you're a step up
from him.

BFN. Paul.

[Ivan Warren]

Post by kerravon86
Um, it's not just a disagreement, it's an attempt
to tell me what I can or can't do on my own
computer. What name would you prefer instead of
Nazi?

I'm not sure I understand all the fuss here..

Here is my view on this :

You (Paul) and a lot of other people - are trying to (and working hard
on it) to drive a project in order to allow individuals to experience
"the mainframe" without the limitation imposed by the architectural
limits set at the time the architecture was defined - and are ready to
go to no ends to do this - including breaking the architecture defined
then in order to achieve your goal.. Fine..

Adam and I (and a also a lot of other people) are trying to participate
to a project in order to allow individuals to experience "the mainframe"
as it was initially intended to be - with its limits, flaws and caveats
- a strict set of rules, a definite philosophy - strictly defined
extensibility mechanism etc.. we don't make the rules : we LIVE by the
rules - and we spend hours discussing the finer details of the rule
books (the POPs)! And are ready to argue to no end that the rules are
adhered to... That's our goal.. Fine..

The good news (and Adam did say that - but you may have skipped this
part - happens) is that "hercules" is an Open Source Project (Not Free
Software - lest you want Jay to look at you with a very stern look - and
believe me - I've met Jay and you DON'T want this to happen) - but in
this VERY context - the outcome is the same : You are welcome and free
to publish your own modifications to the source.. You don't even have to
ask : it is your right under the license under which this project lives
(read the QPL license - it's short and simple).

So having a "paulcules" (ok - probably not a very good project name -
but you get the idea) project wouldn't bother us a bit.. The fact is, if
you come up with an idea we like - we may just ask from you whether we
may integrate it into the "hercules" project.. But overall, the 2
projects are now pursuing 2 completely different goals - and there is
certainly no need to fight about it!

No-one in the hercules development group is EVER going to prevent you
from attempting to achieve your goal - and no-one is going to chastise
you for breaking the rules.. It's just that it's not the same project
altogether.

As a side note, I also noticed you NEVER asked for your modifications to
be included in mainstream hercules.. So I kinda feel you already have
the idea right.

So.. Everyone - cool off - we're fine.. 2 different views, 2 different
goals, 2 different projects - to me, it's as simple as that.

--Ivan

[Adam Thornton]

Post by Ivan Warren

Post by kerravon86
Um, it's not just a disagreement, it's an attempt
to tell me what I can or can't do on my own
computer. What name would you prefer instead of
Nazi?

I'm not sure I understand all the fuss here..
You (Paul) and a lot of other people - are trying to (and working hard
on it) to drive a project in order to allow individuals to experience
"the mainframe" without the limitation imposed by the architectural
limits set at the time the architecture was defined - and are ready to
go to no ends to do this - including breaking the architecture defined
then in order to achieve your goal.. Fine..
Adam and I (and a also a lot of other people) are trying to
participate to a project in order to allow individuals to experience
"the mainframe" as it was initially intended to be - with its limits,
flaws and caveats - a strict set of rules, a definite philosophy -
strictly defined extensibility mechanism etc.. we don't make the rules
: we LIVE by the rules - and we spend hours discussing the finer
details of the rule books (the POPs)! And are ready to argue to no end
that the rules are adhered to... That's our goal.. Fine..
The good news (and Adam did say that - but you may have skipped this
part - happens) is that "hercules" is an Open Source Project (Not Free
Software - lest you want Jay to look at you with a very stern look -
and believe me - I've met Jay and you DON'T want this to happen) - but
in this VERY context - the outcome is the same : You are welcome and
free to publish your own modifications to the source.. You don't even
have to ask : it is your right under the license under which this
project lives (read the QPL license - it's short and simple).
So having a "paulcules" (ok - probably not a very good project name -
but you get the idea) project wouldn't bother us a bit.. The fact is,
if you come up with an idea we like - we may just ask from you whether
we may integrate it into the "hercules" project.. But overall, the 2
projects are now pursuing 2 completely different goals - and there is
certainly no need to fight about it!
No-one in the hercules development group is EVER going to prevent you
from attempting to achieve your goal - and no-one is going to chastise
you for breaking the rules.. It's just that it's not the same project
altogether.
As a side note, I also noticed you NEVER asked for your modifications
to be included in mainstream hercules.. So I kinda feel you already
have the idea right.
So.. Everyone - cool off - we're fine.. 2 different views, 2 different
goals, 2 different projects - to me, it's as simple as that.

OK.

So the mistake on my part was not realizing that all of Paul's
suggestions apply solely to Hercules-380, and that he is not, in fact,
saying that they should be included in mainline Hercules. This was not
at all clear to me.

If indeed all of this future-accomodation stuff is intended solely for
the Hercules-380 fork then it instantly ceases to bother me,
particularly since Jay has restated the goals of the Hercules project
and why those are incompatible with accepting H380 into the mainline.

I have never tried to stop Paul, or anyone else, from running what he
wants on his own machine. However, I am not going to be happy if, in
order to run a current Hercules, I have to change all my existing config
files to turn off options that didn't formerly exist and are now turned
on by default. If all this stuff is only intended for Hercules-380 then
I'll never encounter it anyway, and that's just peachy by me.

I am curious as to whether Paul feels Steve Jobs is a Nazi. I mean,
there's someone who really DOES tell you what you can and cannot do on
devices you presumably own. Unlike me.

As to where you get a z/VM license from to run Hercules: why, IBM.
Because of Jay's Goal #2, it's perfectly possible to run Hercules on a
Linux/390 host. By doing this I have, for instance, successfully run
64-bit VM on a 31-bit machine (namely SNA's old H70, and z/VM 4.4, when
they owned it and had z/VM 4.4 licensed to it). As I said, this is very
slow, but it does provide a 100% legal way (I once asked someone in a
position to know about that--he looked as if he'd swallowed a lemon, but
did concede that IBM did not have any position about what the
intermediate layers of software you used when you ran a licensed product
on the hardware it was licensed to could or could not be; he also gave
me that look that I had by that time long become used to, about "but
you're insane to *do* that"--see also "Windows NT 4.0 on an S/390") to
verify that Hercules does correctly support modern operating systems.

Ivan has concisely and correctly summed up my position vis-a-vis Hercules.

Adam

[kerravon86]

Post by Adam Thornton
So the mistake on my part was not realizing that all of Paul's
suggestions apply solely to Hercules-380, and that he is not,
in fact, saying that they should be included in mainline Hercules.
This was not at all clear to me.

Apparently not clear to me either. When I suggest
putting a DIAG 58 intercept into Hercules, it
doesn't particularly bother me which one it goes
into. I wouldn't want to prejudge the Herc
developers decision on adding a non-default
option.

No need to be nasty about it though.

Post by Adam Thornton
However, I am not going to be happy if, in
order to run a current Hercules, I have to change all
my existing config files to turn off options that
didn't formerly exist and are now turned on by default.

If you are worried about new options, on by default,
in the base Hercules code, then I'm the wrong target,
and you're tilting at windmills anyway.

I don't control in any way shape or form the default
Hercules options, and the people that do, I believe
are already doing what you want them to do.

Post by Adam Thornton
I am curious as to whether Paul feels Steve Jobs is a Nazi.

Not if it's in some sort of contract.

BFN. Paul.

[Adam Thornton]

Post by kerravon86
No need to be nasty about it though.

Only one of us has been calling the other a loser, a pirate, and a Nazi.

Adam

[kerravon86]

Post by Adam Thornton

Post by kerravon86
No need to be nasty about it though.

Only one of us has been calling the other a loser,
a pirate, and a Nazi.

The selective reading seems to be working overtime ...

Post by Adam Thornton
Rather than do that, you consider it acceptable to
break the program for everyone else in order to
accommodate your existing software.
I don't like that approach.
I also know that arguing with you is like arguing
with a wall, and I don't know why I'm bothering.

... if you don't see that as being a nasty attack
on someone who had never said a bad word about you
ever, as far as I know. (I don't recall every
attack, and I judge each message on its own merits
regardless, so you wouldn't know either way anyway).

Oh, and it was lies as well as nasty.

So you can add "no need to lie about what I am
doing" to the top quote.

Look, I only mildly care about these random
specious attacks. They aren't helpful, but
they do limited harm to my development.
But I do care about my right of reply.

Or am I arguing with a wall? You might want to
take your own advice from time to time.

BFN. Paul.

[kerravon86]

Post by Ivan Warren

Post by kerravon86
Um, it's not just a disagreement, it's an attempt
to tell me what I can or can't do on my own
computer. What name would you prefer instead of
Nazi?

I'm not sure I understand all the fuss here..
You (Paul) and a lot of other people - are trying to (and
working hard
on it) to drive a project in order to allow individuals
to experience
"the mainframe" without the limitation imposed by the architectural
limits set at the time the architecture was defined - and are

I wouldn't use those words.

The architecture is rarely a problem. Even the
OS itself is not a great problem. Even things
like 3390-2 support tend to be fairly minor.

Post by Ivan Warren
From time to time there are missing features

people want. In this case, DIAG 58 appears to
be missing.

On MVS there are things like a modern Cobol
missing, and LE/370, and TCP/IP.

Post by Ivan Warren
ready to go to no ends to do this - including
breaking the architecture defined
then in order to achieve your goal.. Fine..

Creating a new architecture is not breaking an
architecture.

Post by Ivan Warren
Adam and I (and a also a lot of other people) are
trying to participate
to a project in order to allow individuals to
experience "the mainframe"
as it was initially intended to be - with its limits,
flaws and caveats
- a strict set of rules, a definite philosophy - strictly defined
extensibility mechanism etc.. we don't make the rules : we
LIVE by the
rules - and we spend hours discussing the finer details of the rule
books (the POPs)! And are ready to argue to no end that the
rules are adhered to... That's our goal.. Fine..

I applaud that goal too. The two goals aren't
incompatible. I can even tell you the rules of
the S/380 architecture should you wish to
support a 4th machine type.

Post by Ivan Warren
The good news (and Adam did say that - but you may have
skipped this part - happens)

No, you seem to have skipped my direct reply to that,
or missed the sequence.

Post by Ivan Warren
is that "hercules" is an Open Source Project (Not Free
Software - lest you want Jay to look at you with a very
stern look - and
believe me - I've met Jay and you DON'T want this to
happen) - but in
this VERY context - the outcome is the same : You are
welcome and free
to publish your own modifications to the source.. You
don't even have to
ask : it is your right under the license under which
this project lives
(read the QPL license - it's short and simple).

You also seem to have skipped my reply where I
said I had already done exactly that.

Post by Ivan Warren
So having a "paulcules" (ok - probably not a very
good project name -
but you get the idea) project wouldn't bother us a bit..

I already have such a project. And various people
do seem to get "bothered", to put it mildly,
regardless.

Post by Ivan Warren
The fact is, if
you come up with an idea we like - we may just ask from
you whether we
may integrate it into the "hercules" project.. But overall, the 2
projects are now pursuing 2 completely different goals -
and there is certainly no need to fight about it!

It's not me who is initiating these fights. You
are better off directing your message to the
original.

Post by Ivan Warren
No-one in the hercules development group is EVER going
to prevent you from attempting to achieve your goal

As I said, I don't know who the OP is. And of
course he lacks the physical means to prevent me.
He tried verbally.

Post by Ivan Warren
- and no-one is going to chastise
you for breaking the rules..

Perhaps you have a different definition of
"chastise", or you very selectively read the
OP's original. I've certainly seen that happen
before.

Post by Ivan Warren
It's just that it's not the same project
altogether.

Sure. And?

Post by Ivan Warren
As a side note, I also noticed you NEVER asked for
your modifications to
be included in mainstream hercules..

That is not correct. Most of my modifications are
in fact tape enhancements (available to all
architectures), and I've asked at least
twice for them to be incorporated.

The very original S/380 enhancements I also asked
for a 4th architecture to be supported, even if it
was a separate executable. I was told no to that.
I wasn't even given a "no" answer to the tape
stuff. Well, one of the posts could be construed
as a "no".

I can provide posts to hercules-390 for both things
if you wish to dispute the above.

Post by Ivan Warren
So I kinda feel you already have the idea right.

If you think I'm doing the right thing, please reply
to the OP, not me.

Post by Ivan Warren
So.. Everyone - cool off - we're fine.. 2 different
views, 2 different
goals, 2 different projects - to me, it's as simple as that.

Again, this needs to go to the OP.

Also, it would be useful if you could bear that in
mind when you discuss S/380 at all. "we're fine"
sounds like the right approach. :-) Some of the
messages sound VERY different from that. I can
provide links to them too.

BFN. Paul.

[Jay Maynard]

I still believe that consensus is on my side--that is, the primary goal of
the Hercules project is accurate emulation of the architecture.

For the record, the goals of the project have not changed in the decade I've
been managing it:

1) Accurate emulation of whatever architecture level the user selects
2) Portability to any Unix-style host system, as well as Windows
3) High performance

Hercules is an open source project. Open source developers scratch their own
itches. A lot of what Hercules is today is there because develoeprs did just
that.

With that said, the Hercules project management has long held that
extensions to the architecture implemented in Hercules must fit in with the
design philosophy of the emulator and the architecure it emualates. This is
where Paul's 380 architecture falls down: it's designed for a single-user
system and contains essentially none of the security features that the
original architecture does. That's why it will not be accepted into the
Hercules mainline code.

I can't stop anyone from forking the project, nor am I particularly
interested in trying. That doesn't mean that I agree with the design
decisions that have been made, or that I will compromise on the goals as
stated above, in the order stated.

[Rocky]

some have a name and some dont because sometimes I send from Oulook and
sometime from Yahoo

Paul
Back to specifics

DIAG 58 is not happening in the forseeable future
LDEV is not happening in the forseeable future

DIAL can be done today with no changes to anything that is OS or hardware
related.

If you were in a real shop looking for an approach to resolve a problem what
would you do.


Tell IBM to change the OS or the hardware. Or look for a workaround that you
could use today and wait for something to happen in the future.
Probably both. But IBM would tell you "in a future release" and your systems
people would come up with a workaround solution.

Constructive input please -
Which of the suggested versions of DIAL is most appealing
Is there another way to do it with DIAL that you would rather see.

Do you see any other uses of FULL screen that the community needs.
I am willing to put some effort in to doing it - one way or another with
DIAL
I would like to have your your very valuable CONSTRUCTIVE INPUT.
if you have no opinion then say that the application doesn't interst you.
(which is a legitimate response)

Repeating you desire for DIAG 58 is very understandable. But as stated
before its only a small part of the solution.
YOU still need a very smart program to work with it. Lets dicuss that side
of the problem.

We can write essentailly the same program using DIAL and if at a later date,
the DIAG and LDEV become availiable we change them very easily.

Almost as easy as switching SIO to DIAG and changing a bit of the code about
handling the Interrupts.
But the application logic will remain unchanged and that is probably most of
the effort.

Can you please refer to the application side which is what I requested
specifically in the previous E-mail.
.
roc




_____

From: H390-VM-***@public.gmane.org [mailto:H390-VM-***@public.gmane.org] On Behalf Of
kerravon86
Sent: Tuesday, July 06, 2010 17:33
To: H390-VM-***@public.gmane.org
Subject: [H390-VM] Re: Fullscreen support for VM/370 Sixpack

Post by rocsystems
HURRAH!
Wish he would say somethig positive once in a while.

You mean something positive like "that's not
impossible, it can be done, watch how I get
this 31-bit program to run under the free
VM we have available"? Or something positive
like "Here's a new version of BREXX. Oh, and
miniunz too. Oh, did I mention BWBASIC. There's
a few more, but I lost track".

Post by rocsystems
Knew a lot of managers like him that had just
enough technical know how to be annoying.

And I still know of a lot of people who get
very pissed off when everything doesn't go
their way. They resort to things like specious
and fallacious arguments. Anything other than
admit it might be them with the problem.

Post by rocsystems
I may be wrong,

You'll always be wrong when you only see what you
want to see.

Post by rocsystems
Perhaps he will volunteer to FIX CP or at least
show us where the one line miracle FIX is

More specious arguments. I never claimed CP
was broken, never said there was a miracle
one-line fix for something that isn't even
broken.

But hey, don't let anything like facts get in
the way of a good story.

And if you weren't blind and dishonest, you might
have noticed that I volunteered to do a hell of
a lot of other stuff.

I don't volunteer to do it for the likes of you
though. There are those who understand and
appreciate it.

And while I don't actually know who you are or
what you've personally contributed to anything,
I assume you've contributed something somewhere,
and unlike you, I appreciate whatever it is that
you have done for the community, irrespective
of the strange desire you seem to have to take
a swipe at someone, for no perceivable (to me)
benefit to yourself.

BFN. Paul.

[kerravon86]

Post by Rocky
some have a name and some dont because sometimes I
send from Oulook and sometime from Yahoo

I see. I had two alternate theories along the way.
One was that someone had hacked the Yahoo ID, and
one was that Yahoo had a bug. Then I had an
afterthought. :-)

Post by Rocky
DIAG 58 is not happening in the forseeable future

Can you explain why? ie how much work is it to
do what you want to do? I'd like to hear that
spelled out just to scope the future work.

Post by Rocky
If you were in a real shop looking for an approach
to resolve a problem what would you do.

Which problem? This problem? I'd purchase z/VM.

Post by Rocky
Tell IBM to change the OS or the hardware.

I can't tell them to do anything.

Post by Rocky
Or look for a workaround that you
could use today and wait for something to happen in the future.

Yes, I'd do this, or live without the functionality,
or put the functionality on another platform, or
something along those lines.

I thought that Internet Explorer idea of Tony's
was pretty snazzy.

And then there's the existing vmconsole.

What exactly are you writing this for if all
you want is a workaround?

Post by Rocky
Probably both. But IBM would tell you "in a future
release" and your systems
people would come up with a workaround solution.

vmconsole is a workaround solution. It's here
right now.

Post by Rocky
Do you see any other uses of FULL screen that the community needs.
I am willing to put some effort in to doing it - one way or
another with DIAL

Well, one thing's for sure. If you do the actual
work for DIAL, and everyone else just talks about
DIAG 58, then DIAL it is! :-)

Post by Rocky
I would like to have your your very valuable CONSTRUCTIVE INPUT.
if you have no opinion then say that the application
doesn't interst you.
(which is a legitimate response)

Which application? Let's assume a non-editor. So
vmconsole won't help. Also assume that it will
eventually end up on a z/VM system, running normal
3270s, so the fancy Internet Explorer is out.

Post by Rocky
Repeating you desire for DIAG 58 is very understandable.
But as stated
before its only a small part of the solution.
YOU still need a very smart program to work with it. Lets
dicuss that side of the problem.

Sure. I assume that z/VM programmers would have an
API rather than directly call DIAG 58? Something
suitable for calling from Cobol?

Hmmm. I have vague recollection of that being
done in CICS itself, with an EXEC CICS READ or
somesuch. I had to write a screen compiler in
one job. The shop used Cobol, but I wrote the
screen compiler in C.

And there was a screen driver, written in
mixed Cobol and C, that used to read those
screens and then form a message to be passed
off to the proper Cobol application.

So the proper Cobol application itself didn't
know anything about screens.

This was the reverse of what you typically
see on a PC, where the main program would
be called, and it decided to start displaying
the screens. The way this shop had it, it was
effectively the screens driving the main
program!

I never really figured out which way around
was the proper way to be doing it. :-)

So they had the screens, the screen compiler,
and the display program that interpreted the
compiled screens.

I remember that I wrote the screen compiler in
3 passes. My boss said it should be possible
with 2, but at a particular juncture I needed
a value I didn't have, so just made it go
through again.

Post by Rocky
We can write essentailly the same program using
DIAL and if at a later date,
the DIAG and LDEV become availiable we change them very easily.

Sure.

Post by Rocky
Almost as easy as switching SIO to DIAG and changing
a bit of the code about handling the Interrupts.

Sure. I said long ago that the main thing was to
have an API to hide it all behind.

Post by Rocky
But the application logic will remain unchanged and
that is probably most of the effort.

Yes.

Post by Rocky
Can you please refer to the application side which
is what I requested specifically in the previous E-mail.

Ok. Given that Mike has already mentioned he
wanted to port KICKS, can't you use the CICS
interface? Assume it will exist, and you can
test your app on MVS while waiting.

BFN. Paul.

[Robert O'Hara]

Post by kerravon86

Post by Rocky
DIAG 58 is not happening in the forseeable future

Can you explain why? ie how much work is it to
do what you want to do? I'd like to hear that
spelled out just to scope the future work.

Paul, implementing DIAG 58 support as IBM did in extensions to VM/370 R6 (BSEPP and SEPP) is a couple of thousand lines of code in CP. I've looked at that code, and it is non-trivial.

As Dave stated in an earlier post, part of the problem is that CP has to manage the transition between simulated line mode (RUNNING / MORE... etc) and the fullscreen mode driven by an application program via DIAG 58. Remember that at any moment CP may want to display an asynchronous message on the user's terminal, and thus we go from fullscreen mode to line mode, then after the user has read the message and hit CLEAR or PA2, back to fullscreen mode, WITHOUT THE FULLSCREEN APP EVER KNOWING ANYTHING HAPPENED. This is not simple to do.

So what I think IS practical for us hobbyists to use an alternate approach (a second, attached terminal) which avoids all of the above. The good news is that it will be compatible with z/VM: a fullscreen program written to use an attached 3270 on VM/370 should work just fine on z/VM. And it will work with any 3270 emulator.

What it will not do is run a z/VM fullscreen program that uses DIAG 58. So we won't have compatibility in that direction.

And as you point out Paul, if someone later does get DIAG 58 working, then any programs written for this support can be easily converted.


Bob

[Ivan Warren]

... and hit CLEAR or PA2, back to fullscreen mode, WITHOUT THE FULLSCREEN APP EVER KNOWING ANYTHING HAPPENED. This is not simple to do.

Actually, the running program *IS* made aware of the switch : First, an
ATTN is posted when 3215 output has to be displayed (so that a Read
Buffer or Read Modified is performed)..

Second, a ATTN+CE+DE+UC is posted on a write if the write wasn't an
ERASE/WRITE or ERASE/WRITE Alternate following a switch back to
fullscreen mode in order to notify the application that the screen needs
a complete rebuild.

I'm not sure what happens when a Fullscreen I/O is attempted over a 3215
emulation when the terminal is disconnected (or logged in using a non
capable 3270 device) - but this has to be described somewhere.

On modern VM systems, when TERM CONMODE 3270 is set - this Doesn't
happen (because there is no such provision in the 3270 protocol) - and
this is why the screen *MAY* get garbled in this situation.. But with
the Fullscreen 3270 over 3215 (Aka Fullscreen DIAG 58) - there IS
provision for that - and thuis - the screen is always clean.

--Ivan

[kerravon86]

Post by Robert O'Hara

Post by kerravon86

Post by Rocky
DIAG 58 is not happening in the forseeable future

Can you explain why? ie how much work is it to
do what you want to do? I'd like to hear that
spelled out just to scope the future work.

Paul, implementing DIAG 58 support as IBM did in
extensions to VM/370 R6 (BSEPP and SEPP) is a couple
of thousand lines of code in CP. I've looked at
that code, and it is non-trivial.
As Dave stated in an earlier post, part of the problem
is that CP has to manage the transition between
simulated line mode (RUNNING / MORE... etc) and the
fullscreen mode driven by an application program via DIAG 58.

And if you skip that transition code, and rely
on the user to just take care when running
their program (no more onerous than managing
an entire second terminal???), what does the
task get stripped down to?

And secondly, what does the task get stripped
down to if it's a matter of intercepting
DIAG58 in Hercules/380?

Post by Robert O'Hara
And as you point out Paul, if someone later does
get DIAG 58 working, then any programs written for
this support can be easily converted.

Sure. An actual DIAG 58 will help make sure of
that though. :-)

BFN. Paul.

[Dave Wade]

----- Original Message -----
From: "kerravon86" <kerravon86-/***@public.gmane.org>
To: <H390-VM-***@public.gmane.org>
Sent: Tuesday, July 06, 2010 11:49 PM
Subject: [H390-VM] Re: Fullscreen support for VM/370 Sixpack

Post by kerravon86

Post by Robert O'Hara

Post by kerravon86

Post by Rocky
DIAG 58 is not happening in the forseeable future

Can you explain why? ie how much work is it to
do what you want to do? I'd like to hear that
spelled out just to scope the future work.

Paul, implementing DIAG 58 support as IBM did in
extensions to VM/370 R6 (BSEPP and SEPP) is a couple
of thousand lines of code in CP. I've looked at
that code, and it is non-trivial.
As Dave stated in an earlier post, part of the problem
is that CP has to manage the transition between
simulated line mode (RUNNING / MORE... etc) and the
fullscreen mode driven by an application program via DIAG 58.

And if you skip that transition code, and rely
on the user to just take care when running
their program (no more onerous than managing
an entire second terminal???), what does the
task get stripped down to?
And secondly, what does the task get stripped
down to if it's a matter of intercepting
DIAG58 in Hercules/380?

As there is a partial implementation of DIAG 58 in CP intercepting that may
be none trivial.

Post by kerravon86

Post by Robert O'Hara
And as you point out Paul, if someone later does
get DIAG 58 working, then any programs written for
this support can be easily converted.

Sure. An actual DIAG 58 will help make sure of
that though. :-)
BFN. Paul.
------------------------------------
Yahoo! Groups Links

[kerravon86]

Post by Dave Wade

Post by kerravon86
And secondly, what does the task get stripped
down to if it's a matter of intercepting
DIAG58 in Hercules/380?

As there is a partial implementation of DIAG 58 in CP
intercepting that may be none trivial.

Interception is simple. Even partial interception.
I have an option in Herc380 to only partially
intercept SVC 120 for use by MVS too.

Similar situation for DOS/VS.

BFN. Paul.

[Robert O'Hara]

I'm not sure how implementing DIAG 58 in Hercules helps, but I may be missing something. Now I suspect you could define a new DIAG code (or even a new instruction) that provided a new way to do terminal I/O to the world outside (Windows, Linux, etc). But that would be incompatible with everything...

Or were you thinking along other lines?

Bob

Post by kerravon86

Post by Dave Wade

Post by kerravon86
And secondly, what does the task get stripped
down to if it's a matter of intercepting
DIAG58 in Hercules/380?

As there is a partial implementation of DIAG 58 in CP
intercepting that may be none trivial.

Interception is simple. Even partial interception.
I have an option in Herc380 to only partially
intercept SVC 120 for use by MVS too.
Similar situation for DOS/VS.
BFN. Paul.

[kerravon86]

Post by Robert O'Hara
I'm not sure how implementing DIAG 58 in Hercules
helps, but I may be missing something.

Not sure why you think it isn't helpful - you
can see how executables would then work under
both VM/3x0 and z/VM, right? All while obeying
z/VM rules.

Post by Robert O'Hara
Now I
suspect you could define a new DIAG code (or
even a new instruction) that provided a new
way to do terminal I/O to the world outside
(Windows, Linux, etc). But that would be
incompatible with everything...

That would indeed be the case. But I wasn't
advocating that, was I? If I was, it was an
aside.

Post by Robert O'Hara
Or were you thinking along other lines?

I focus on the technical aspects of the executable
running in user space. And get everything else
to adjust around that.

BFN. Paul.

[Tony Harminc]

Post by kerravon86
I focus on the technical aspects of the executable
running in user space. And get everything else
to adjust around that.

If you apply UNIXy terminology and concepts to VM you are likely to
continue making conceptual blunders and bad design decisions.

CP provides virtual machines for a living, and their interface is
defined in the appropriate Principles of Operation manual. CP -- like
Hercules -- is not an application platform, and attempts to turn it
into one are misguided.

Tony H.

[kerravon86]

Post by Tony Harminc

Post by kerravon86
I focus on the technical aspects of the executable
running in user space. And get everything else
to adjust around that.

If you apply UNIXy terminology and concepts to VM you are likely to
continue making conceptual blunders and bad design decisions.

Man, what a statement.

Let's see.

Someone (a South Korean) once lent me a DVD called
"The Secret" (from America), telling me how great
it was. It was the usual baseless assertions from
the "spirit industry", and they made certain
claims that I knew they wouldn't have any evidence
for, and that anyone with a brain would have been
able to rip apart. Thanks to the internet, you can
quickly find those people, just by adding "skeptic"
in google to whatever baseless assertion that was
made, and it was truly a joy to watch them rip it
apart. I then forwarded the links to the guy, and
also added that he should try visualizing Kim
Jong Il being swallowed by a giant snake, to prove
how effective it was. Apparently not very, and
surprise surprise, no answer to all the skeptical
comments.

If you consider "producing executables that allow
tasks to be accomplished" as a sign of a
"conceptual blunder", then I am in fact after more
"conceptual blunders". If you consider "code ported
from other environments working with 0 changes" to be
"bad design", then I hope to, and certainly plan to,
come up with more and more "bad designs" in the future,
so you may as well create a macro to list out your
bad logic.

A bit like the US military really. After it lost
the "unwinnable (because to think otherwise would
shatter the left's worldview) war" in Iraq, and I
see the troops are withdrawing with their tails
between their legs as we speak, what would be
great is if they could now invade Iran, and lose
there in 3 weeks. Oh, and losing in 3 days in
Syria and Hizbullastan would also be fantastic.
Perhaps losing in 3 hours in Cuba would be the
icing on the cake.

Post by Tony Harminc
CP provides virtual machines for a living, and their interface is
defined in the appropriate Principles of Operation manual.
CP -- like
Hercules -- is not an application platform, and attempts to turn it
into one are misguided.

CMS provides a programming interface either for a
living, or a side-effect, I don't really care.
Its interface is defined somewhere-or-other, I've
forgotten where. I think I saw the manual once
when I needed to look something up for SVC 202.
By following that interface, you can get something
that *actually works*.

That is apparently a radical concept in your circles -
producing working executables - particularly ones
that also work on real iron - as opposed to
pontificating about how those executables will
either not work, or will necessarily be bad,
while always falling short of being able to point
to a single byte in those executables that is actually
bad, when every byte is in full conformance with both
the published CMS specs and the published C90
specs.

So yes, with those definitions, of course everything
I do is, and will continue to be, "misguided". You
can continue to repeat that every 10 minutes if you
like, and eventually I'll create a pre-canned
response to that, listing all your Orwellian
definitions, and ending with a recommendation that
Vaporware Incorporated's non-existent executables
are theoretically far superior to the ones that I
have produced to date, and therefore people should
visualize running those instead. After, surely
that's what the V in VM is all about?

Or perhaps I'll just write a keyword like
"boomshanka" in this one, so that I can quickly
retrieve this one for next time. I was thinking
of saying something else, but calling someone
"misguided", "blundering", "a bad designer",
are just below my tolerance threshold, that I
will take them as technical points of dispute
rather than personal insults.

Man, the irony of that (based on other recent
and not-recent messages) kills me though.

BFN. Paul.

[Ivan Warren]

Post by kerravon86

Post by Tony Harminc

Post by kerravon86
I focus on the technical aspects of the executable
running in user space. And get everything else
to adjust around that.

If you apply UNIXy terminology and concepts to VM you are likely to
continue making conceptual blunders and bad design decisions.

Man, what a statement.
Let's see.

I didn't read through all the banter..

But..

Could we keep "gas chambers", "Kim Jong Il", "Cuba", "Syria", "Iraq" and
whatnot out of it ?

We understand you have strong feelings about what you are doing - again
- I say it's fine - but please, allow us to have our own views about it
without throwing hyperboles into it.

Keep it civil..

Thanks,

--Ivan

[kerravon86]

Post by Ivan Warren

Post by kerravon86

Post by Tony Harminc

Post by kerravon86
I focus on the technical aspects of the executable
running in user space. And get everything else
to adjust around that.

If you apply UNIXy terminology and concepts to VM you are likely to
continue making conceptual blunders and bad design decisions.

Man, what a statement.
Let's see.

I didn't read through all the banter..
But..
Could we keep "gas chambers", "Kim Jong Il", "Cuba",
"Syria", "Iraq" and whatnot out of it ?
We understand you have strong feelings about what you
are doing - again
- I say it's fine - but please, allow us to have
our own views about it
without throwing hyperboles into it.
Keep it civil..

Your message is being totally and utterly ignored,
based on the fact that the sentiments, just as
stated (except replacing "Iraq" with the far more
personal "blunders" and "bad design") should have
been directed to the original message, and before
I even replied.

If you wish to continue pissing into the wind, and
don't mind getting exactly the same response, go
right ahead.

The trouble has never been one of me minding
people having other views, but of others minding
me having my own view. Until you grasp this
concept you will never solve the root cause.

BFN. Paul.

[Robert O'Hara]

Got it now. By implementing fullscreen 3270 support outside of CP in Hercules (via DIAG or whatever) it might be possible to deliver that support to a CMS program with much less effort than implementing it in CP. Have to think about this a bit more...

Bob

Post by kerravon86

Post by Robert O'Hara
I'm not sure how implementing DIAG 58 in Hercules
helps, but I may be missing something.

Not sure why you think it isn't helpful - you
can see how executables would then work under
both VM/3x0 and z/VM, right? All while obeying
z/VM rules.

Post by Robert O'Hara
Now I
suspect you could define a new DIAG code (or
even a new instruction) that provided a new
way to do terminal I/O to the world outside
(Windows, Linux, etc). But that would be
incompatible with everything...

That would indeed be the case. But I wasn't
advocating that, was I? If I was, it was an
aside.

Post by Robert O'Hara
Or were you thinking along other lines?

I focus on the technical aspects of the executable
running in user space. And get everything else
to adjust around that.
BFN. Paul.

[kerravon86]

Post by Robert O'Hara
Got it now. By implementing fullscreen 3270 support
outside of CP in Hercules (via DIAG or whatever) it
might be possible to deliver that support to a CMS
program with much less effort than implementing it in CP.

Exactly. I'm surprised you didn't know that. It's
a restatement of what we've been talking about for
years. Many radical things can go in there. 31-bit
is just one thing. GETMAIN intercepts for MVS and
DOS/VS are already available. I haven't put one in
for CMS, since it was adequately changed in CMS/CP
long ago.

TCP/IP is already in Jason's version. So is native
file support. There are "moves" to incorporate both
into the normal Hercules, due to the way they were
implemented. (not sure if DIAG 58 can be implemented
within that paradigm or not).

It has been suggested that DB2/SQL be made available
the same way (that might fit into the standard
paradigm for additions too - not sure).

Now it's DIAG 58's turn for analysis.

Post by Robert O'Hara
Have to think about this a bit more...

Yes, I haven't seen an adequate explanation as to
why this should be difficult under the specified
constraints.

I've mainly seen "reasons" why analysis shouldn't
be done in the first place.

Obviously I could do the analysis myself, but I
did my first ever diag (8) a couple of weeks ago,
so I'm not the best person to do that. And I'm
busy doing a large disassembly anyway. I do make
time to point out when people are trying to dodge
the analysis due to "politics" though, instead of
simply saying "while I totally disagree with this
approach, the direct technical answer to your
question is that about 30 lines of C code in
diag.c are required to pass the buffer down to
a terminal, and it doesn't need to be dialled.
Another 25 lines of C in general2.c are required
to provide an I/O mapping. The latter can be
avoided if you stick with dialled, because the
CMS executables themselves will be the same
regardless".

Note that all of the above has been the basis of
some full-on "debates" for years. Hmmmm. Mostly
in MVS areas though.

Anyway, as I said, I prefer to focus on the
integrity of the executable (by the way, Unixy
people sometimes complain when I say "if the
(Unix) executable abends ..."), and adjust
CMS/CP/Hercules/humans around that, as a
distant, minor, secondary consideration. So
long as the application software is being
written nicely, OS upgrades are transparent,
and just an annoying time when you have to
log off because someone is making a change
you didn't ask for, and don't need, and is
taking the machine away when you're trying
to use it.

My work laptop does massive downloads of software
upgrades, blowing my quota sometimes. I complained
that I wouldn't mind a 1 GB software download, as
a once-off, if it fixed the 20 Sametime bugs that
I reported, and that I've been after a fix for for
7 years, but 1 GB for crap that is of no interest
to me, and has a reasonable chance of interfering
with my productivity as they take away the normal
menu in Microsoft Word etc etc so that I can't find
anything (fortunately I don't have to do too much
work using Word), should at least be done in
off-peak hours instead of blowing my quota.

While I obviously do OS work too, I do that with
a different hat on, and still with a focus on
meeting the application programmer on his terms,
ie ensuring that his executables are being run
in accordance with his expectations.

Perhaps that is a source of confusion too.

BFN. Paul.

Post by Robert O'Hara

Post by kerravon86

Post by Robert O'Hara
I'm not sure how implementing DIAG 58 in Hercules
helps, but I may be missing something.

Not sure why you think it isn't helpful - you
can see how executables would then work under
both VM/3x0 and z/VM, right? All while obeying
z/VM rules.

Post by Robert O'Hara
Now I
suspect you could define a new DIAG code (or
even a new instruction) that provided a new
way to do terminal I/O to the world outside
(Windows, Linux, etc). But that would be
incompatible with everything...

That would indeed be the case. But I wasn't
advocating that, was I? If I was, it was an
aside.

Post by Robert O'Hara
Or were you thinking along other lines?

I focus on the technical aspects of the executable
running in user space. And get everything else
to adjust around that.
BFN. Paul.

[Robert O'Hara]

Paul,

But I think that 3270 support to the CMS console via Hercules is signficantly different than your 31 bit addressing support. This is because the CMS fullscreen app using the Hercules interface will be competing for the screen with CP.

Now I may be worrying about a problem that is more theoretical than real. (I don't really need to be worried about messages from other users, because there are no other users.) However I still get unsolicited messages from CP about spool files, the monitor, and the fact that it is midnight.

What would happen when CP wrote the screen while I was half-way through typing the Declaration of Independence??? In other words, I'm not sure that it is practical to "ignore the problem", as I believe you suggested in an earlier post (if I understood you correctly).

I don't have the answer yet, and as it has been decades since I've done any 3270 programming, I have some reading to do first. And before that I want to get the update to the SixPack posted.

Bob

Post by kerravon86

Post by Robert O'Hara
Got it now. By implementing fullscreen 3270 support
outside of CP in Hercules (via DIAG or whatever) it
might be possible to deliver that support to a CMS
program with much less effort than implementing it in CP.

Exactly. I'm surprised you didn't know that. It's
a restatement of what we've been talking about for
years. Many radical things can go in there. 31-bit
is just one thing. GETMAIN intercepts for MVS and
DOS/VS are already available. I haven't put one in
for CMS, since it was adequately changed in CMS/CP
long ago.

[kerravon86]

Post by Robert O'Hara
But I think that 3270 support to the CMS console via
Hercules is signficantly different than your 31 bit
addressing support. This is because the CMS fullscreen
app using the Hercules interface will be competing for
the screen with CP.

Sure.

Post by Robert O'Hara
Now I may be worrying about a problem that is more
theoretical than real. (I don't really need to be
worried about messages from other users, because there
are no other users.) However I still get unsolicited
messages from CP about spool files, the monitor, and
the fact that it is midnight.

First of all, I would be inclined to just get
it working to the stage where people have the
luxury to complain about unsolicited messages
interfering with their editing session at
midnight.

Having said that, and bearing in mind that the
below complications should not be added to the
effort required to get fullscreen operational,
nor counted in the lines of code required, in
my opinion:

Is there a CP option to say "ignore unsolicited
messages"?

How many lines of CP code would be required to
add such a feature, either globally or for a
particular terminal (whichever is easiest)?

Post by Robert O'Hara
What would happen when CP wrote the screen
while I was half-way through typing the
Declaration of Independence???

It would overwrite your screen, and you'd lose
that page of data input. In addition, when you
hit enter etc, the editor may get an unexpected
response and not know what to do with it.

Post by Robert O'Hara
In other words, I'm not sure that it is
practical to "ignore the problem", as I believe
you suggested in an earlier post (if I understood
you correctly).

How about "defer the problem", "so as to not make
the problem so difficult that no-one does anything
when they realise its beyond their ability to
conclude successfully by themselves".

Post by Robert O'Hara
I don't have the answer yet, and as it has been
decades since I've done any 3270 programming,
I have some reading to do first. And before that
I want to get the update to the SixPack posted.

Sure.

So long as the problem remains in the state "the
jury is still out as to whether there is a simple
workaround or not", I'm happy. It's premature
conclusions of "not possible, due to reasons that
I'm not willing to defend in the free marketplace
of ideas, but just trust me, even if I was wrong
last time, and the time before that too" that I'm not
happy about.

I'm willing to inspect Hercules code if someone
can say what they're looking for. I believe we
isolated a problem with DIAG 8 like that a few
weeks ago. I remember my initial diagnosis being
incorrect, but the seemingly correct diagnosis
coming in the next iteration, with fairly minimal
effort.

I have a C compiler and I'm prepared to use it. :-)

BFN. Paul.

[Dave Wade]

Post by Rocky
-----Original Message-----
Sent: 10 July 2010 08:33
Subject: [H390-VM] Re: Fullscreen support for VM/370 Sixpack

Post by Robert O'Hara
But I think that 3270 support to the CMS console via
Hercules is signficantly different than your 31 bit
addressing support. This is because the CMS fullscreen
app using the Hercules interface will be competing for
the screen with CP.

Sure.

Post by Robert O'Hara
Now I may be worrying about a problem that is more
theoretical than real. (I don't really need to be
worried about messages from other users, because there
are no other users.) However I still get unsolicited
messages from CP about spool files, the monitor, and
the fact that it is midnight.

First of all, I would be inclined to just get
it working to the stage where people have the
luxury to complain about unsolicited messages
interfering with their editing session at
midnight.
Having said that, and bearing in mind that the
below complications should not be added to the
effort required to get fullscreen operational,
nor counted in the lines of code required, in
Is there a CP option to say "ignore unsolicited
messages"?

You can do "SET MSG OFF" and "SET WNG OFF" which reduces the chatter but
still doesn't eliminate it entirely.
Its probably good enough for now.

Post by Rocky
How many lines of CP code would be required to
add such a feature, either globally or for a
particular terminal (whichever is easiest)?

No idea on that....

Post by Rocky

Post by Robert O'Hara
What would happen when CP wrote the screen
while I was half-way through typing the
Declaration of Independence???

It would overwrite your screen, and you'd lose
that page of data input. In addition, when you
hit enter etc, the editor may get an unexpected
response and not know what to do with it.

Post by Robert O'Hara
In other words, I'm not sure that it is
practical to "ignore the problem", as I believe
you suggested in an earlier post (if I understood
you correctly).

How about "defer the problem", "so as to not make
the problem so difficult that no-one does anything
when they realise its beyond their ability to
conclude successfully by themselves".

Post by Robert O'Hara
I don't have the answer yet, and as it has been
decades since I've done any 3270 programming,
I have some reading to do first. And before that
I want to get the update to the SixPack posted.

Sure.
So long as the problem remains in the state "the
jury is still out as to whether there is a simple
workaround or not", I'm happy. It's premature
conclusions of "not possible, due to reasons that
I'm not willing to defend in the free marketplace
of ideas, but just trust me, even if I was wrong
last time, and the time before that too" that I'm not
happy about.
I'm willing to inspect Hercules code if someone
can say what they're looking for. I believe we
isolated a problem with DIAG 8 like that a few
weeks ago. I remember my initial diagnosis being
incorrect, but the seemingly correct diagnosis
coming in the next iteration, with fairly minimal
effort.
I have a C compiler and I'm prepared to use it. :-)
BFN. Paul.
------------------------------------
Yahoo! Groups Links

[Harold Grovesteen]

In the context of VM/370, not VM/380 where the "rules" are more
"flexible", a DIAGNOSE in Hercules is not directly accessable to
software running in a VM/370 virtual machine. The virtual machine runs
in problem state. A DIAGNOSE requires privileged state. Hence, when a
VM/370 virtual machine issues a DIAGNOSE, a program interrupt will occur
and VM/370 will intercept the DIAGNOSE. Nothing stops VM/370 CP from
then using a Hercules DIAGNOSE to assist in delivering the results
needed by the virtual machine, but the support for DIAGNOSE X'58' would
be needed in VM/370 CP for it to do what the virtual machine is
expecting. That appears to have a lot of complications that nobody is
willing to take on.

As far as DIAGNOSE X'58' emulation in Hercules is concerned, there are
no Hercules project rules that would prohibit it from being implemented,
per se. I haven't reviewed DIAGNOSE X'58' to know if it would make
sense or not. Hercules implements a number of VM DIAGNOSE codes for
programmers or programs, think here OpenSolaris, that wants to use them
as they would in VM. In fact DIAGNOSE is the architected mechanism for
adding to the architectures supported by Hercules.

With regards to the Hercules rules, I probably sit between Ivan and
yourself. You appear to see no rules other than what code lets you do.
I definitely don't go that far. But, I also view the developers in the
role of developers of the architecture rather than as users of the
architecture with regards to Hercules. I perceive architecture
emulation as the starting point for Hercules, not the end goal. This
puts me someplace in the middle between the two extreme positions
represented by most individuals on the developers list and you, Paul.

I lobbied heavily for inclusion of the Jason Winters instructions into
Hercules as non-privileged instructions. Instructions are regularly
added to these architectures. Mind you, the Jason Winters instructions
need a lot of work, but the discussion was about how to add them. The
conclusion to which the developers arrived was that

* a real external interface for adding instructions and other
components such as devices is needed,
* the Jason Winters instructions should use that interface and
* the community does need Jason Winters instructions supported as
non-privileged instructions.


Needless to say, it was a lively debate on the developer's list, but the
conclusion is one I am very happy with. The real advance of that effort
is a decided mechanism for doing these kinds of things. The only answer
we had before was pretty much "use a DIAGNOSE" or "no." Another
response is called for. Until of course the interface is built, those
are pretty much still the only answer the developers have. I did
volunteer to rework the Jason Winters instructions in conformance with
the new interface as a practical test of the interface. When you
actually use an interface many flaws or quirks are revealed.

Harold Grovesteen

Post by kerravon86

Post by Robert O'Hara
I'm not sure how implementing DIAG 58 in Hercules
helps, but I may be missing something.

Not sure why you think it isn't helpful - you
can see how executables would then work under
both VM/3x0 and z/VM, right? All while obeying
z/VM rules.

Post by Robert O'Hara
Now I
suspect you could define a new DIAG code (or
even a new instruction) that provided a new
way to do terminal I/O to the world outside
(Windows, Linux, etc). But that would be
incompatible with everything...

That would indeed be the case. But I wasn't
advocating that, was I? If I was, it was an
aside.

Post by Robert O'Hara
Or were you thinking along other lines?

I focus on the technical aspects of the executable
running in user space. And get everything else
to adjust around that.
BFN. Paul.
------------------------------------
Yahoo! Groups Links

[kerravon86]

Post by Harold Grovesteen
With regards to the Hercules rules, I probably sit between Ivan and
yourself. You appear to see no rules other than what code lets you do.
I definitely don't go that far.

Hi Harold. An interesting message. I can't point
to anything I disagree with, but let me just
clarify one thing.

When I write code, and stick a:

#if FEATURE_S380

around it, I consider that the code doesn't even
exist, doesn't break any rules, and that there
should be no barrier to inclusion other than
political.

That rule would still apply if a separate executable
was compiled.

The bulk of Hercules/380 changes are in fact
tape processing, not S380-specific stuff, so
that code does exist, and if the only barrier
to inclusion of that code is a lack of a

#if FEATURE_ENHANCED_TAPE_PROCESSING

I would be happy to add that, so that once again,
the code ceases to exist, and ceases to violate
any rules, real or imaginary.

I realise that the Herc developers are not obliged
to take any of my code, but it would be nice to
know if the barriers are technical or political
or personal. If it's personal, I can always ask
a friend to post the code diffs. After all, if
I can end up as the "liason officer" between
Jason Winter and the Herc developers, absolutely
anything is possible.

BFN. Paul.

[Joe Monk]

OK I am confused here.



CP is virtualized hardware. CMS is the OS running on top of CP.



If I am running in CMS, and I issue a DIAG, why does CP not use its own
vdev's to handle the DIAG?



DIAG 58 has been included in CP since VM/370 rel 3 (Page 247)
http://www.bitsavers.org/pdf/ibm/370/vm370/GC20-1807-3_VM370_SysPgmrGuide_Ja
n75.pdf



"The DIAGNOSE instruction cannot be used in a virtual machine for its normal
function. If a virtual machine attempts to execute a DIAGNOSE

instruction, a program interrupt returns control to CP. Since a DIAGNOSE
instruction issued in a virtual machine results only in

returning control to CP, and not in performing normal DIAGNOSE functions,
the instruction is used for communication between a virtual

machine and CP."



"Because DIAGNOSE operates differently in a virtual machine than in a real
machine, a program should determine that it is operating in a

virtual machine before issuing a DIAGNOSE, and prevent execution of a
DIAGNOSE when in a real machine. The Store CPU ID (STIDP) instruction

provides a program with information about the CPU in which it is executing,
including the CPU version number. If STIDP is issued from a

virtual machine the version number will be 'FF', in the first byte of the
CPUID field."



Why does HERCULES need to be modified to support an instruction that is
being used for CMS to CP communications?



Someone earlier mentioned LEDIT. Here is the Screen handling code from
LEDIT. I see nothing about this requiring privileged mode, or any mods to
HERCULES.



*---------------------------------------------------------------------*
LED30330

* *
LED30340

* SCRIO executes a CCW for a 3270 display. The condition code and *
LED30350

* R15 are set to indicate success or failure. The residual count *
LED30360

* is returned in r0. *
LED30370

* *
LED30380

*---------------------------------------------------------------------*
LED30390

SCRIO STM R0,R15,SAVE3 SAVE REGISTERS
LED30400

LH R2,NUMPNDWR ANY PENDING WRITES?
LED30410

LTR R2,R2 IF NOT, CONWAIT USELESS
LED30420

BZ NOCWAIT
LED30430

SSM =X'FF' ENABLE INTERRUPTS
LED30440

LA R1,=CL8'CONWAIT' CLEAR ANY PENDING CMS CONSOLE I/O
LED30450

SVC 202
LED30460

DC AL4(1) IGNORE ERRORS
LED30470

SSM =X'00' SET NO INTERRUPTION
LED30480

L R1,SAVE3+4 RESTORE POINTER TO CCW
LED30490

NOCWAIT LH R2,CONADDR DISPLAY ADDRESS CUU
LED30500

WAITDISP DS 0H
LED30510

TIO 0(R2) RESET AL PENDING INTERRUPTIONS
LED30520

BC 6,WAITDISP AND LOOP IF SOME MORE
LED30530

BC 1,BYE ERROR IF DISPLAY IS NOT OPERATIONNEL
LED30540

*
LED30550

* ISSUE DIAGNOSE
LED30560

*
LED30570

DIAG EQU *
LED30580

DIAG R1,R2,X'58' ISSUE DIAGNOSE
LED30590

BC 8,TIO1 ALL OK GO WAIT FOR THE END OF INPUT/OUTPUT
LED30600

BC 2,DIAG BUSY REISSUE DIAGNOSE
LED30610

BC 4,CHKCSW GO LOOK AT CSW
LED30620

BC 1,BYE ERROR IF DISPLAY IS NOT OPERATIONNEL
LED30630

*
LED30640

* WAIT FOR THE END OF THE INPUT/OUTPUT AND CHECK CSW
LED30650

*
LED30660

TIO1 DS 0H
LED30670

TIO 0(R2) WAIT FOR THE END OF INPUT/OUTPUT
LED30680

BC 8,CHKCSW OK GO ON
LED30690

BC 2,TIO1 BUSY KEEP LOOPING
LED30700

BC 1,BYE ERROR IF NOT OPERATIONNEL
LED30710

TM CSW+4,X'B0' CSW STORED + ATTN CTLUNIT END BUSY
LED30720

BNZ TIO1 YES THEN HANDLE AS BUSY
LED30730

CHKCSW DS 0H
LED30740

CLI CSW+5,X'00' SOME PROBLEM WITH THE CHANNEL ?
LED30750

BNE BYE YES NOTHING WE CAN DO
LED30760

LH R0,CSW+6 GET RESIDUAL COUNT
LED30770

CLI CSW+4,X'0C' DID WE GET CE+DE ?
LED30780

BE GOTCEDE YES WE ARE FINISHED
LED30790

CLI CSW+4,X'08' DID WE GET CE ONLY ?
LED30800

BE TIO2 YES GO WAIT FOR DE
LED30810

CLI CSW+4,X'8E' IS THIS ERROR CODE '8E' FROM CP ?
LED30820

BE SCRERR8E YES GO TELL THE CALLER
LED30830

TM CSW+4,X'02' UNIT CHECK ?
LED30840

BO BYE
LED30850

* BO SENSE YES GO DO A SENSE
LED30860

TM CSW+4,X'B0' ATTN OR CTL UNIT END OR BUSY ?
LED30870

BNZ DIAG IF YES REISSUE THE DIAGNOSE
LED30880

TM CSW+4,X'0C' DID WE GET AT LEAST CE OR DE ?
LED30890

BZ DIAG NO REISSUE THE DIAGNOSE
LED30900

TIO2 DS 0H
LED30910

TIO 0(R2) WAIT FOR DE
LED30920

BC 2,TIO2 BUSY KEEP LOOPING
LED30930

BC 1,BYE ERROR IF NOT OPERATIONAL
LED30940

*
LED30950

* ALL OK EXIT
LED30960

*
LED30970

GOTCEDE DS 0H
LED30980

SR R15,R15 SUCCESS RC
LED30990

B SCRRTN
LED31000

SPACE
LED31010



Regards,



Joe



From: H390-VM-***@public.gmane.org [mailto:H390-VM-***@public.gmane.org] On Behalf Of
Harold Grovesteen
Sent: Sunday, July 11, 2010 8:59 AM
To: H390-VM-***@public.gmane.org
Subject: Re: [H390-VM] Adding to Hercules or VM [WAS: Re: Fullscreen support
for VM/370 Sixpack]





In the context of VM/370, not VM/380 where the "rules" are more "flexible",
a DIAGNOSE in Hercules is not directly accessable to software running in a
VM/370 virtual machine. The virtual machine runs in problem state. A
DIAGNOSE requires privileged state. Hence, when a VM/370 virtual machine
issues a DIAGNOSE, a program interrupt will occur and VM/370 will intercept
the DIAGNOSE. Nothing stops VM/370 CP from then using a Hercules DIAGNOSE
to assist in delivering the results needed by the virtual machine, but the
support for DIAGNOSE X'58' would be needed in VM/370 CP for it to do what
the virtual machine is expecting. That appears to have a lot of
complications that nobody is willing to take on.

As far as DIAGNOSE X'58' emulation in Hercules is concerned, there are no
Hercules project rules that would prohibit it from being implemented, per
se. I haven't reviewed DIAGNOSE X'58' to know if it would make sense or
not. Hercules implements a number of VM DIAGNOSE codes for programmers or
programs, think here OpenSolaris, that wants to use them as they would in
VM. In fact DIAGNOSE is the architected mechanism for adding to the
architectures supported by Hercules.

With regards to the Hercules rules, I probably sit between Ivan and
yourself. You appear to see no rules other than what code lets you do. I
definitely don't go that far. But, I also view the developers in the role
of developers of the architecture rather than as users of the architecture
with regards to Hercules. I perceive architecture emulation as the starting
point for Hercules, not the end goal. This puts me someplace in the middle
between the two extreme positions represented by most individuals on the
developers list and you, Paul.

I lobbied heavily for inclusion of the Jason Winters instructions into
Hercules as non-privileged instructions. Instructions are regularly added
to these architectures. Mind you, the Jason Winters instructions need a lot
of work, but the discussion was about how to add them. The conclusion to
which the developers arrived was that

* a real external interface for adding instructions and other
components such as devices is needed,
* the Jason Winters instructions should use that interface and
* the community does need Jason Winters instructions supported as
non-privileged instructions.


Needless to say, it was a lively debate on the developer's list, but the
conclusion is one I am very happy with. The real advance of that effort is
a decided mechanism for doing these kinds of things. The only answer we had
before was pretty much "use a DIAGNOSE" or "no." Another response is called
for. Until of course the interface is built, those are pretty much still
the only answer the developers have. I did volunteer to rework the Jason
Winters instructions in conformance with the new interface as a practical
test of the interface. When you actually use an interface many flaws or
quirks are revealed.

Harold Grovesteen

kerravon86 wrote:



--- In H390-VM-***@public.gmane.org, "Robert O'Hara" <mailto:***@...>
<***@...> wrote:


I'm not sure how implementing DIAG 58 in Hercules
helps, but I may be missing something.



Not sure why you think it isn't helpful - you
can see how executables would then work under
both VM/3x0 and z/VM, right? All while obeying
z/VM rules.



Now I
suspect you could define a new DIAG code (or
even a new instruction) that provided a new
way to do terminal I/O to the world outside
(Windows, Linux, etc). But that would be
incompatible with everything...



That would indeed be the case. But I wasn't
advocating that, was I? If I was, it was an
aside.



Or were you thinking along other lines?



I focus on the technical aspects of the executable
running in user space. And get everything else
to adjust around that.

BFN. Paul.




------------------------------------

Yahoo! Groups Links

[Tony Harminc]

I thought that Internet Explorer idea of Tony's was pretty snazzy.

Wow - I'm not sure if I'd rather be called a Nazi or be accused of
having an Internet Explorer idea. Fortunately neither applies to me.

For the record, I use IE only on those rare occasions when I have to
access a Microsoft web page that they have intentionally broken for
standard browsers.

Tony H.

[Ivan Warren]

Post by Rocky
We can write essentailly the same program using DIAL and if at a later
date, the DIAG and LDEV become availiable we change them very easily.

Actually

- Fullscreen I/O to the 3215 emulated console when it is connected to a
3270 device or Issuing I/O to a dedicated (or DIALed) 3270
- LDEV

Are 2 very different concepts which are completely unrelated to one another.

To make a POSIX kind of analogy, The possibility to do I/O to a 3270
device is to TERMIOS what LDEVs are to PTYs

What you may be suggesting is an API to construct 3270 data streams
(which is the actual real difficult part) and that would related to
curses/ncurses..

What VM is missing *right now* is the possibility to perform fullscreen
I/O to a 3270 logged in to a VM in 3215 emulation mode.. However, any
program written to support Dedicated/Dialed terminals in VM/370 would
work up to VM/ESA S/370 edition - and possibly up to z/VM 6.1 with a
"SET 370ACCOMM ON" - WITHOUT any modification to the interface
implemented by hercules[1].

What was suggested was to use the same semantics as what is used for
DIAG 58/3270 through 3215 for DIALed/Dedicated 3270s so that when - DIAG
58 is eventually fully implemented in VM/370 - the required change is
minimal [2].

LDEVs Are *WAY* more complicated to implement than Fullscreen DIAG 58
will ever be. That's because this pretty much entails constructing
dynamic RDEVs to hook up to the VDEVs... It took 15 years for IBM to
even get it right.

--Ivan

[1] Hercules isn't an "emulator" per-se - it is one of the existing
implementations of the interface contract specified by the various
"Principles Of Operation" manuals.

[2] There are a few differences : You don't do a X'05' to perform an
Erase/Write - You do a X'29' and set the control flags to indicate you
want to perform an erase/write.. Then again - even if an API was built
using original 3270 I/O mechanics, changing it to support fullscreen
DIAG 58 wouldn't be that bad - The OVERALL 3270 buffer formating remains
exactly the same (which - again - is the difficult part).

[kerravon86]

Post by Adam Thornton

Post by kerravon86

Post by Adam Thornton
operating system for the documented architecture.

I think some/most programmers have a more important
level of compatibility - it's how their apps behave
under the OS running under the architecture under
the emulator.
When compared with a later version of the OS under
real iron.

I think you are absolutely, completely wrong there.

And I think you are.

Post by Adam Thornton
That is not "compatibility".

It is indeed, when a binary works on VM/3x0 using
a z/VM interface that was never in the original
VM/370.

Post by Adam Thornton
That is an added feature which is, by its very nature,
incompatible with the actual goal of emulation.

Um, different people have different goals. While
you appear to be content running a bootlegged
z/VM, or even a legal z/VM, others don't run
that, and aren't happy to run that.

Post by Adam Thornton
It may be convenient for you.

Crikey, a feature that is convenient for end users?
What will they think of next?

Post by Adam Thornton
It is not compatible with the goal of accurate emulation.

Read above. Not everyone in the world shares your
One True Worldview, even if you think they should.

Post by Adam Thornton

Post by kerravon86

Post by Adam Thornton
That is, if your changes break VM, they are not compatible.

And a second point is whether any particular
behaviour can be switched off via an option.
If it can, any disadvantage, real or theoretical,
is a moot point.

No, no it is not.

Yes, yes it is. Unless you come to the table with
a One True Worldview, anyway. Oh, I see.

Post by Adam Thornton
Now, I will concede that if your new compatibility-breaking
features can be switched ON with an option, and if that option
is not present, then software that actually depends on the
emulator continuing to work like it always has, which is
also how it is documented to behave in the Principles of
Operation, never knows the difference, then that is not
horrible, just irritating.

You are irritating when you try to hamper people
trying to switch on such an option.

Post by Adam Thornton
And it's irritating because *I*, and I think Roger
Bowler, and some not-inconsiderable fraction of the
users of Hercules expect it to be a System/370,
System/390, and zSeries emulator.

And? You're free to keep the option switched off,
so it behaves the way the "non-inconsiderable"
fraction of Hercules want it to behave. Meanwhile,
I and another not-inconsiderable fraction of
Hercules users are free to switch it on.

Wow. Like we should coin a word for this situation
or something. Something like "freedom of choice".

Post by Adam Thornton
You appear to want it to be some sort of hybrid MVS
simulator thingy.

DIAG 58 is used by MVS, is it? I was under the
impression that MVS 3.8j already did fullscreen
perfectly fine.

Post by Adam Thornton
The two things are not the same, and I frankly
resent its being steered away from being an emulator,

Ah yes, there's always those who resent others from
doing anything that is outside their control.

And when they have an army to back them up, they
bring out the gas chambers.

Post by Adam Thornton
which is actually useful to me (and what the project
has historically been), as I have a good deal of interest
in the z/VM, z/Linux, and z/OpenSolaris worlds,

Ah, so you don't need it personally, so therefore
anyone who "wastes" time on something you don't
need, should go take a hike. Check.

Post by Adam Thornton
towards an MVS simulator that provides some sort of

Funny, I thought we were talking about a z/VM
simulator. Not much use to someone who runs a
bootleg z/VM, I have to admit.

BTW, I also have a partial z/VSE simulator available.
Also activated via an option (it intercepts some
SVC, I forget which one now).

Post by Adam Thornton
future-architecture-accomodation-mode or something,
which is completely useless to me.

Oh diddums. Someone is writing sofware on their
own computer, and you can't use it because you
have a bootleg z/VM, or rich enough to afford
the real thing.

Post by Adam Thornton
The thing is, of course, the architecture has a
well-defined mechanism for extending it. That's
how DIAG works. Your problem is that you would have
to rewrite applications--some of which you don't have
the source for--to exploit these new DIAGs. Rather
than do that, you consider it acceptable to break
the program for everyone else in order to accommodate
your existing software.

Pardon? Which program is broken for everyone
else? MVS I'm familiar with, and I'm not aware
of any program being broken. VM is still being
negotiated, but the way I envisioned it, no
programs were going to be broken either.

Post by Adam Thornton
I don't like that approach.

Well I don't like dictators, so we're even.

Post by Adam Thornton
I also know that arguing with you is like arguing
with a wall, and I don't know why I'm bothering.

I don't know why you bother raising specious
arguments, but I do know why I bother to make
it clear that they are specious and dictatorial,
or at least "my way or the highway", since you
lack the physical means to stop me. Some people
consider that to be far more despicable than
opening up APIs for programmers. (I'm also aware
that some very vocal people besides yourself are
the exact reverse, and that's fine too).

BFN. Paul.

[Adam Thornton (FSF)]

Post by kerravon86
Ah yes, there's always those who resent others from
doing anything that is outside their control.
And when they have an army to back them up, they
bring out the gas chambers.

I invoke Godwin's Law.

Adam

[Ivan Warren]

Post by kerravon86
And when they have an army to back them up, they
bring out the gas chambers.

Does this qualify as an instance of Godwin's law ?

--Ivan