Re: PC connection via twinax ?

[Douglas Handy <dhandy1@xxxxxxxxxxxxx>]

Steve,

>If a 3rd party dev wanted to enable your interactive pgm to write 
>direct to a twinax terminal, bypassing a dspf and cfint:  is the 
>twinax interface documented to enable this?

You can bypass a dspf by using the DSM api's.  These are in essence wrappers to
the various 5250 data stream commands.  Or you can use a DSPF with the USRDFN
keyword -- the so-called User Defined Data Stream (aka UDDS) predecessor to the
DSM api collection.  Although it passes via a DSPF, UDDS is for all practical
purposes a low-level access to the direct 5250 data streams.

But I don't think that the CFINT govenor implementation is likely to have
*anything* to do with whether or not a DSPF is used.  For that matter, UIM
doesn't use display files either.  Most (all?) of IBM's programs use UIM instead
of a DSPF.  Yet I'm sure the workload is counted towards the interactive limit
just as DSPF activity is.  (That's just a SWAG, but I assume it is.)

I think the CFINT is implmented at the 5250 data stream level -- no matter what
process creates the data stream (DDS, UIM, DSM, UDDS).  Last I looked, it would
seem impossible to talk to a twinax dumb workstation without using the 5250 data
stream and having the workstation attached to a WS controller.  How else you
going to talk to one of those without using 5250 data streams?  That's all they
understand

So drop the DSPF part from the question.  It now becomes:  Is it possible for a
3rd party program to intercept and take control of the WS controller so that you
can talk to it "directly" and thereby talk "directly" to a twinax terminal?  And
even if you did, would that make it sidestep the CFINT routines to detect 5250
data stream traffic?

I can't provide definitive answers to those questions -- but IMHO one of the
hallmarks of a "real" operating system is that it *does* prevent you from having
direct access to certain hardware components.  Witness the difference between
Win 9x and NT, and the compatibility problems with games etc which will not run
on NT because they are blocked from techniques which they never should have used
in the first place...

>a valid response is: what is gained by ibm in not releasing what I have 
>described.  It is not a threat to system integrity.

It's not?  Allowing a user program "direct" access to hardware is not a threat
to system integrity?   You mean NT would be no less stable if it allowed games
et al to manipulate all the hardware registers and OS hooks possible in Win9x?
Then why doesn't MS just open back up access to the hardware from NT?  They
could have had the convergence of the Win 9x and NT code base done much sooner
I'm sure.

Allowing a RPG program "direct" access to the WS controller instead of just
direct access to the data streams (ala DSM or UDDS) is no threat to the
stability of the other programs also using the WS controller?

I trow not.

>also, maybe there could be more twinax type attachments. Any use for a  cd r/w 
>device attached thru twinax and controlled by a user written rpg pgm?  Or fax 
>modem?

This seems to me the exact *opposite* of what you want.  I want fewer twinax
connections, not more.

We *used* to see more twinax type attachments -- like the tape drives I
mentioned for a S/36.  Or data transfer box between the 3x and 400.  I believe
some vendors do (or did?) have fax controllers which attach via twinax.

Face it.  Twinax is not fast -- you don't want to use it for something like CDRW
access.  And just think what one of the those twinax tape drives or the data
transfer box would do to the CFINT govenor.  It would probably think 5250 data
traffic was going through the roof.

It *used* to be that PCs used 5250 traffic even for batch processes like data
transfer -- I know because I used to write them even before PC Support/36
existed as I explained in a previious post.

Now network attached PCs can do batch and client/server work without using 5250
data streams to do it.  And they don't count against the CFINT govenor.

Why in the world would I want to attach some new device via slow twinax when it
could be connected via TCP/IP to a fast network interface or some other bus?

Doug