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

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

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.

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).

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

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

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

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

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

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
>

On 11/12/21 2:53 PM, Louis Ohland wrote:
> Emulation, fine, great.

I think you're thinking something different than IBM when you read the
word "emulation".

Emulation in the P/390 context means that the drivers & software present
a virtual (emulated) device to the System/390 processor on the P/390 card.

Think about something like a "virtual disk" or "virtual NIC" or "virtual
serial port" in VirtualBox. The guest sees it as real hardware. But
the virtual hardware is created by the drivers & software running in
OS/2 (or AIX for R/390).

The driver & software running in OS/2 / AIX uses the real underlying
hardware, e.g. the Multiprotocol Adapter/A, to provide the necessary
physical functionality.

This means that OS/390 running on the P/390 card sees what it thinks is
the proper networking hardware which the Multiprotocol Adapter provides
connectivity to.

In this case, the connectivity is what's required for SDLC. As in the
Multiprotocol Adapter can be connected to the proper modem to talk to a
real physical mainframe on the other end of the WAN circuit.

> So, we have an S/390 sitting in a Server 500. You run the OS/2 app to
> actually start it.

OS/2 runs the drivers and software that do more than /just/ /start/ the
P/390 CPU.

Remember, the P/390 (et al.) card(s) only have a System/390 CPU and
associated memory. ALL other hardware that OS/390 sees is emulated by
the drivers running in OS/2. The DASD that OS/390 sees are emulated by
an AWS driver (I don't remember which one). Those emulated disks are
saved as files on a file system provided by OS/2; FAT, HPFS, or JFS.
(Maybe even mapped network drive from any network that OS/2 supports.)

> If you have a supported WAC / multiport, you can speak native SDLC
> over a physical cable.

That's the job of the driver & application. They take the data that
OS/390 writes to the virtual / emulated device, do the necessary
conversion to use the physical Multiprotocol Adapter and talk to the
physical world.

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

That's what the driver that responsible for the emulation does. It
converts from the emulated ~> virtual hardware presented to the P/390 ~>
OS/390 to the real physical hardware like the Multiprotocol Adapter/A.

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

I think you're reading too much into and getting caught on the word
"emulation".

--
Grant. . . .
unix || die

Never played with a P/390.

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.

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

On 11/12/2021 18:30, Grant Taylor wrote:
> On 11/12/21 2:53 PM, Louis Ohland wrote:
>> Emulation, fine, great.
>
> I think you're thinking something different than IBM when you read the
> word "emulation".
>
> Emulation in the P/390 context means that the drivers & software present
> a virtual (emulated) device to the System/390 processor on the P/390 card.
>
> Think about something like a "virtual disk" or "virtual NIC" or "virtual
> serial port" in VirtualBox.  The guest sees it as real hardware.  But
> the virtual hardware is created by the drivers & software running in
> OS/2 (or AIX for R/390).
>
> The driver & software running in OS/2 / AIX uses the real underlying
> hardware, e.g. the Multiprotocol Adapter/A, to provide the necessary
> physical functionality.
>
> This means that OS/390 running on the P/390 card sees what it thinks is
> the proper networking hardware which the Multiprotocol Adapter provides
> connectivity to.
>
> In this case, the connectivity is what's required for SDLC.  As in the
> Multiprotocol Adapter can be connected to the proper modem to talk to a
> real physical mainframe on the other end of the WAN circuit.
>
>> So, we have an S/390 sitting in a Server 500. You run the OS/2 app to
>> actually start it.
>
> OS/2 runs the drivers and software that do more than /just/ /start/ the
> P/390 CPU.
>
> Remember, the P/390 (et al.) card(s) only have a System/390 CPU and
> associated memory.  ALL other hardware that OS/390 sees is emulated by
> the drivers running in OS/2.  The DASD that OS/390 sees are emulated by
> an AWS driver (I don't remember which one).  Those emulated disks are
> saved as files on a file system provided by OS/2; FAT, HPFS, or JFS.
> (Maybe even mapped network drive from any network that OS/2 supports.)
>
>> If you have a supported WAC / multiport, you can speak native SDLC
>> over a physical cable.
>
> That's the job of the driver & application.  They take the data that
> OS/390 writes to the virtual / emulated device, do the necessary
> conversion to use the physical Multiprotocol Adapter and talk to the
> physical world.
>
>> How can you speak via emulation to the remote device? Over what? LAN?
>
> That's what the driver that responsible for the emulation does.  It
> converts from the emulated ~> virtual hardware presented to the P/390 ~>
> OS/390 to the real physical hardware like the Multiprotocol Adapter/A.
>
>> I surfed the overview,so it isn't clear. With a real SDLC device, no
>> intellectual problems. Emulation?
>
> I think you're reading too much into and getting caught on the word
> "emulation".
>
>
>

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

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...

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

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.

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