These have more firepower than that needed by a mere ASYNC adapter.

Can someone with actual knowledge of BSC / SDLC / HLDC tell us more?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thursday, 11 November 2021 at 14:31:46 UTC, Louis Ohland wrote:

These have more firepower than that needed by a mere ASYNC adapter.

Can someone with actual knowledge of BSC / SDLC / HLDC tell us more?

BiSync and SDLC protocols were used for remote connection of various peripheral I/O devices to IBM mainframes, via Transmission Control Units (TCUs - 27xx - e.g. 2703) and, later, Front-End Processors (FEPs - 37xx - e.g. 3705, 3725, 3745, 3720). These
protocols provided much more sophisticated addressing (multipoint) and error control capabilities (cyclic redundancy checksum - CRC).

Remote Job Entry (RJE) stations - card reader, punch and printer combinations. 3270 Information Display System cluster controllers - 3274, 3275, 3276, 3174, 2210 etc.
Various translation "gateways" to interconnect diverse networks together - DEC/SNA, Wang, Burroughs.
Inter-company network links - SNA Network Interconnection (SNI).

HDLC was an industry standard development from SDLC.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

I could buy that for a dollar.

On 11/11/2021 11:21, WBSTClarke wrote:

These protocols provided much more sophisticated addressing (multipoint) and error control capabilities (cyclic redundancy checksum - CRC).

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 11/11/2021 14:30, Louis Ohland wrote:

These have more firepower than that needed by a mere ASYNC adapter.

Can someone with actual knowledge of BSC / SDLC / HLDC tell us more?

Why sync not async? Sync eliminates of start and stop bits and the
transmission of data in blocks improves throughput. On an async line
each character has a start bit and at least one stop bit. That means
that for an 8-bit character 20% of the bits are wasted.

On a sync link there no start and stop bits and a Cyclic Redundancy
Check takes the place of parity. Each block has structure that allows
multiple devices on a single host (printer, punch, plotter, terminal) or multiple hosts (multi drop line)

On a mainframe the 37xx handles all the start and end of block detection
and only interrupts the host when whole block has been received.

so more efficient than having to process separate character.

BiSync was the original protocol and was used for remote block-mode
terminals, and remote job entry. I remember having a bi-sync line from
an IBM1130 into a 360/67 for remote job entry....

... so the data was transferred in blocks, and information in a block
header allowed it to be routed to a printer, punch, plotter or console.

It was also widely used to to support remote 3270 terminals on 3274 or
3174 controllers. This works because the 3174 buffers the input and only
sends a block to the host when the user hits certain keys.

SDLC/HDLC are pretty much the same except SDLC is EBCDIC and HDLC is
ASCII. HDLC is pretty much "SNA" and "HDLC" the X25 link layer protocol.
The both have frame numbers, flow control and other nice things.

Dave

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 11/11/2021 21:03, David Wade wrote:

On 11/11/2021 14:30, Louis Ohland wrote:

These have more firepower than that needed by a mere ASYNC adapter.

Can someone with actual knowledge of BSC / SDLC / HLDC tell us more?

Why sync not async? Sync eliminates of start and stop bits and the transmission of data in blocks improves throughput. On an async line
each character has a start bit and at least one stop bit. That means
that for an 8-bit character 20% of the bits are wasted.

On a sync link there no start and stop bits and a Cyclic Redundancy
Check takes the place of parity. Each block has structure that allows multiple devices on a single host (printer, punch, plotter, terminal) or multiple hosts (multi drop line)

On a mainframe the 37xx handles all the start and end of block detection
and only interrupts the host when whole block has been received.

so more efficient than having to process separate character.

BiSync was the original protocol and was used for remote block-mode terminals, and remote job entry. I remember having a bi-sync line from
an IBM1130 into a 360/67 for remote job entry....

... so the data was transferred in blocks, and information in a block
header allowed it to be routed to a printer, punch, plotter or console.

It was also widely used to to support remote 3270 terminals on 3274 or
3174 controllers. This works because the 3174 buffers the input and only sends a block to the host when the user hits certain keys.

SDLC/HDLC are pretty much the same except SDLC is EBCDIC and HDLC is
ASCII. HDLC is pretty much "SNA" and "HDLC" the X25 link layer protocol.
The both have frame numbers, flow control and other nice things.

Dave

oops forgot on bit. P390 uses it to implement these protocols on a PS/2

Dave

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

With what does the P/390 either emulate or use SDLC/HLDC?

On 11/11/2021 15:06, David Wade wrote:

oops forgot on bit. P390 uses it to implement these protocols on a PS/2

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 11/11/21 2:55 PM, Louis Ohland wrote:

With what does the P/390 either emulate or use SDLC/HLDC?

I would think that the AWS software that's part of the P/390(-E) would
use it to form an SDLC connection to other IBM Mainframe equipment.

The AWS driver probably translate / abstract the Multiprotocol Adapter/A
and make it look like a channel attached piece of equipment to what's
running on the P/390(-E).



--
Grant. . . .
unix || die

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 11/11/2021 21:55, Louis Ohland wrote:

With what does the P/390 either emulate or use SDLC/HLDC?

Not sure what you are asking. From looking at the P390 new users guide
it can be used with the AWSICA driver to emulate the 9370/43xx
integrated communications adaptor or the older 2703.

The P/390 manual does say the later WAC adaptors are preferred but it
does give info on driver support for Multi protocol Adaptors.

I have one but have yet to try it.

On 11/11/2021 15:06, David Wade wrote:

oops forgot on bit. P390 uses it to implement these protocols on a PS/2

Dave

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Emulation, fine, great.

So, we have an S/390 sitting in a Server 500. You run the OS/2 app to
actually start it. If you have a supported WAC / multiport, you can
speak native SDLC over a physical cable.

How can you speak via emulation to the remote device? Over what? LAN?

I surfed the overview,so it isn't clear. With a real SDLC device, no intellectual problems. Emulation?

On 11/12/2021 15:08, David Wade wrote:

On 11/11/2021 21:55, Louis Ohland wrote:

With what does the P/390 either emulate or use SDLC/HLDC?

Not sure what you are asking. From looking at the P390 new users guide
it can be used with the AWSICA driver to emulate the 9370/43xx
integrated communications adaptor or the older 2703.

The P/390 manual does say the later WAC adaptors are preferred but it
does give info on driver support for Multi protocol Adaptors.

I have one but have yet to try it.

On 11/11/2021 15:06, David Wade wrote:

oops forgot on bit. P390 uses it to implement these protocols on a PS/2

Dave

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 11/12/21 5:49 PM, Louis Ohland wrote:

Never played with a P/390.

I've played with my P/390-E some.

BUT... the OS/390 makes a virtual "whizz-bang" adapter. OS/390 can fake
all sorts of "whizz-bang adapters" on the actual physical adapters
installed on the real system.

I don't know that that statement is correct.

I don't think that OS/390 can create any virtual hardware. I think all
of the virtualization happens in VM and / or -- what is now called --
PR/SM (pronounced "prism"). I believe that OS/390 uses the hardware
that is presented to it and that's it. Said hardware can do a fair bit
of virtualization itself, e.g. Open Shared Adapters (OSAs), and / or VM.

But in general, IBM mainframes can do EXTREME virtualization via PR/SM
and / or VM. It's possible to have PR/SM divide a physical box into
multiple Logical PARtitions (LPARs) each of which is a first level
instance of VM. Each VM supports at least a second level VM. I believe
I've heard of people doing a third level of VM. My understanding is
that VM can conceptually nest many levels, if not infinitely.

This is really far beyond the elastic reality I enjoy...

IBM has been doing virtualization since the '70s. I think that IBM has forgotten more than some newer virtualization providers know.



--
Grant. . . .
unix || die

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

And in the specific instance of the Multi-Protocol Adapter/A using the "Remote 5250 Emulation Program", it emulates both the terminal and the 5x94 kink for that terminal...

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 13/11/2021 04:00, Grant Taylor wrote:

On 11/12/21 5:49 PM, Louis Ohland wrote:

Never played with a P/390.

I've played with my P/390-E some.

BUT... the OS/390 makes a virtual "whizz-bang" adapter. OS/390 can
fake all sorts of "whizz-bang adapters" on the actual physical
adapters installed on the real system.

I don't know that that statement is correct.

I don't think that OS/390 can create any virtual hardware.  I think all
of the virtualization happens in VM and / or -- what is now called --
PR/SM (pronounced "prism").  I believe that OS/390 uses the hardware
that is presented to it and that's it.  Said hardware can do a fair bit
of virtualization itself, e.g. Open Shared Adapters (OSAs), and / or VM.

But in general, IBM mainframes can do EXTREME virtualization via PR/SM
and / or VM.  It's possible to have PR/SM divide a physical box into multiple Logical PARtitions (LPARs) each of which is a first level
instance of VM.  Each VM supports at least a second level VM.  I believe I've heard of people doing a third level of VM.  My understanding is
that VM can conceptually nest many levels, if not infinitely.

In this case the "emulation" is done in OS/2. So we (usually) don't have
any 3380 DASD (disks), card readers, card punches, line printers,
9-track tapes.

The device drivers in OS/2 provide an emulation or mapping of PC files
onto these devices. So you can have files on the PS/2 disk that appears
as a 3380 DASD, card decks, tapes or other devices.

In the case of the MP/A the lines appear as 27xx lines on the 370.

This is really far beyond the elastic reality I enjoy...

IBM has been doing virtualization since the '70s.  I think that IBM has forgotten more than some newer virtualization providers know.

Dave

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 11/11/21 07:30, Louis Ohland wrote:

These have more firepower than that needed by a mere ASYNC adapter.

Can someone with actual knowledge of BSC / SDLC / HLDC tell us more?

An async UART can rely on a small FIFO, interrupts to the host CPU, and
flow control to implement the encoding.

With sync serial, you have tighter timing constraints and waiting for
the host CPU to process interrupts for every tick are going to cause
overhead in the case of an RTOS where you may be able to do this
reliably or lost sync or frames in the case of a general purpose system.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 11/13/21 2:45 AM, David Wade wrote:

In this case the "emulation" is done in OS/2. So we (usually) don't have
any 3380 DASD (disks), card readers, card punches, line printers,
9-track tapes.

"usually" is a very operative word. It's possible to add a card that
provides Bus & Tag connectivity.

I've heard tell that you can use a B&T / ESCON gateway to access things attached to ESCON. I've heard people make noise about chaining through
an ESCON / FICON gateway to access things attached to FICON.

}:-D



--
Grant. . . .
unix || die

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)