Harold Grovesteen wrote:
> Status Modifier was also used with polled BSC communication lines on
> 270x and 370x Emulation Program. The polling was a sequnce of CCW's
> followed by a TIC back to the start of the poll sequence. When a device
> responded, Status Modifier dropped the CCW chain out of the polling loop
> to read the response and then provide an interrupt to the CPU. This
> allowed the polling to be handled totally by the hardware without CPU
> intervention.
>
> There might be other examples out there too.

Early start-stop devices (asynchronous terminals) had to
maintain a line connection because the early communications gear
didn't do this.

For funny TIC uses, there was PCI Fetch, and Page Data set I/O.

Gerhard Postpischil
Bradford, VT

•  11
  New Members
•  2
  New Files

Harold Grovesteen wrote:
> There might be other examples out there too.
>
> Lindy, "Status Modifier" is a hint to what you might want to read to
> learn about this if curious.
>
>
Another common use of breaking out of TIC loop is when doing CKD I/Os..
A typical CKD CCW chain is usually something like :

Set file mask and other control CCWs..
Seek
loop:
Search ID (equal, greater, etc..)
TIC to 'loop'
some read or write

In this case, a SEARCH CCW will post a Status Modifier when the search
matches.

One of the advantages of this way of doing things is that it allows a
channel to disconnect from the Control Unit while the various records
are passing under the disk head.

It is also possible for a program (the CPU) to change the TIC to a NOP..
But under VM, one has to take extra steps to do this, because contrary
to 'bare' hardware, VM will pre-fetch the CCWs and executes its own CCW
chain when requested to do so by VM (there is a DIAG to indicate the CCW
chain was altered).

Another side note is that TIC is the *ONLY* CCW which allows for a
length of 0 (because it never goes out to the control unit).

--Ivan

[Non-text portions of this message have been removed]

•  9
  New Members
•  2
  New Files

Yes, presumably I/O bound. I don't know the details of this, just the
major issue (trying to get three days worth of processing done in two).
This involves a large Oracle ERP type system.

Harold Grovesteen

kerravon86 wrote:

> --- In hercules-390 <at> yahoogroups.com
> <mailto:hercules-390%40yahoogroups.com>, Harold Grovesteen
> <h.grovsteen <at> ...> wrote:
> > And yes, I/O capacity is the real problem.
> ...
> > processes with the same problem, a weekend process in development
> > that takes three days to run in a two-day weekend.
>
> What is the total volume of data:
>
> 1. read over the entire run
> 2. written over the entire run
>
> The CPU is fast enough, and the job is I/O-bound,
> correct?
>
> BFN. Paul.
>
>

•  9
  New Members
•  2
  New Files

On Friday 21 Nov 2008, August Treubig wrote:
> Centos Linux 5.2 x64 at
>
> 2.6.18-92.1.6.el5

I am running 2.6.23 so I doubt that is the issue. I had another thought this
morning: are you pre-loading the tun module or does it load on demand?

Another tack would be to try to use the Herc auto-operator facility to issue
the echo when TCP/IP comes active.

HTH
--
------------------------------------------------------
Robin Atwood

•  9
  New Members
•  2
  New Files

On Nov 20, 2008, at 2:54 PM, Tony Harminc wrote:

>> MVS has an undocumented I/O facility which effectively bridges S/370
>> through XA through SP, and it has remained remarkable stable (and
>> identical) from 1975 to at least the late 1990s, and possibly to the
>> present.
>>
>> A number of folks have used my 1975 paper on STARTIO to implement
>> quite a number of functions.
>
> It might just be worth making clear that despite the identical
> sounding names, STARTIO and SIO are only conceptually related. STARTIO
> is an MVS macro and callable service; SIO is a 370-architecture
> machine instruction, that of course works no matter what, if any,
> operating system is running.

I have uploaded an interpretation of my ca. 1975 STARTIO program. My
original was lost.

I have explained the origin of the program, its copyright status, and
I have included an important erratum which corrects the result of an
error on the part of the person who interpreted the program from its
original.

As of 1995, the program was verified to work with all versions of MVS
then available.

The title is Amdahl_Tech_Topics_STARTIO_Program.pdf .

Peter

On Nov 20, 2008, at 2:22 PM, Lindy Mayfield wrote:

> The only mentions of this I found were Peter5322 asking if anyone
> has a copy. And a link to EXCP driver in 3.8j:
> http://www.mainframe.eu/mvs38/asm/Data%20management%20(IEC)/IECVEXCP

What you have referenced, on http://www.mainframe.eu/mvs38/, is the
IBM code for one important function, the EXCP driver (EXCP/XDAP/EXCPVR).

But, not all that is required, nor is possible, for using the STARTIO
facility is contained within IECVEXCP alone.

Additional references include IEWFETCH, and certain modules within
JES2 and JES3.

Oh, and IMS/VS, just to cover all the basis (and the basics).

The title of my publication was, again, "The STARTIO Facility of
MVS" (Amdahl Technical Topic 2), and was published in about 1976.

Amdahl discarded the masters before it could be reprinted.

•  9
  New Members

2008/11/20 Lindy Mayfield <lindy.mayfield <at> ssf.sas.com>:
> This part is absolutely 100% clear now. It gets me from the hardware to the first card read to the code that is executed next.
>
> Even though I now know what really happens, I still do not see it in the documentation. I've read it over many times. The 370 is here and the IPL sequence is on page 54.
> http://bitsavers.org/pdf/ibm/370/princOps/GA22-7000-4_370_Principles_Of_Operation_Sep75.pdf
>
> I have to give a ton of credit to the Hercules people who can read these POPs and write code using them.

Actually the POP from the earliest S/360 days has been a marvel of
clear writing. Some time in the 1970s, iirc the US Defense Department
did an evaluation of the clarity and level of detail of documentation
of a number of hardware vendors, and they concluded that the IBM (at
the time) S/370 was the only one that had close to enough detail to
actually understand what the system was doing. Or perhaps more
important, to understand when a system was behaving according to the
doc, and when it wasn't. DEC and UNIxxx and the Bunch were just about
hopeless.

Of course the POP has expanded just a little from those days... Up to
about the end of S/370, I think it was not unreasonable for an
individual to actually know the whole thing. Certainly most of us
didn't have every opcode memorized, or the layout of every bit in
every control register, but armed only with a yellow card we could
write or debug anything.

These days I would think that's close to, though not completely, impossible.

> I spent a lot of time going through the zArch POP looking for x'9C'
> SIO instruction. I finally had to conclude that perhaps it isn't in there.

Yup - the I/O architecture was one of the big changes between S/370
and XA. If you look at how S/370 I/O works, there are some bottlenecks
that show up particularly in a multiprocessor situation. But even on a
uniprocessor, when you issue SIO, there is only a single Channel
Address Word in low storage, so the CPU cannot continue until at least
that CAW has been fetched. SIOF ("fast release" helps somewhat, but
there is also the problem that channels are tied to CPUs in a fixed
way, though towards the end they intrioduced switchable channel sets.
But it was getting to be a bit of a kludge... So in XA and above the
instruction is Start Subchannel (SSCH), and there is a whole much more
complex architecture of device numbers, ORBs, and so on to make it
work.

I do really recommend learning the S/370 way first, because it's much
easier to follow. And what you learn about actual channel programming
is almost entirely applicable to XA; it's just starting the I/O and
handling interrupts that's a lot different.

Tony H.

•  9
  New Members

On Thursday 20 Nov 2008, August Treubig wrote:
> But having that said. As I said in the original post, the
> tap0/proxy_arp file does not appear until after TCPIP actually
> opens the device.
>
> Your solution gets the following:
>
> sh ./dofix.sh
> HHCAO001I Hercules Automatic Operator thread started;
> tid=4221E940, pri=0, pid=30307
> ./dofix.sh: line 2: /proc/sys/net/ipv4/conf/tap0/proxy_arp: No such
> file or directory
> HHCPN013I EOF reached on SCRIPT file. Processing complete.
>
> Even though the devlist shows:
>
> devlist 0d20
> 0:0D20 3088 LCS Port 00 IP (tap0) open

Oh. that is not the case on my Linux system, you can write the file before
issuing the IPL command. I am using a .oat file but I doubt that makes a
difference. What level of kernel do you have on your host system?
--
------------------------------------------------------
Robin Atwood

•  9
  New Members

200 terminals? That is just one floor in an moderate size office building.
We have over 50,000 PCs as terminals spread over a state among 500 buildings
or more (anywhere from 5 - 500 in a building). 4 mainframes, about 10 z
processors total, runs 70-90% busy, some weeks 100% all day long, 2 ESS
800s, 8 ESS F20s, 2,200 Mod 9 volumes about 18,000Gb online, Second computer
center for DR testing and recovery purposes (used to have the 4 mainframes
split between buildings.) I/O rates on 8 ESCON channels (1Gbit/sec each)
reaching 80% for 3 hours while taking backups after midnight every night.
During the day the I/O channels run at 30-40% capacity all day long, evening
batch work gets it to 50-60%
On Thu, Nov 20, 2008 at 4:16 AM, kerravon86 <kerravon86 <at> yahoo.com.au> wrote:

> --- In hercules-390 <at> yahoogroups.com, "BruceTSmith" <brucetsmith <at> ...>
> wrote:
> >
> > Want a nice app to port, try a big CICS system, with a few thousand
> > remote terminals, each running a different transaction. Sure, you
> can
> > do it on "a PC", if you want to invest in a huge rack of servers.
> But
> > now the total cost doesn't look all that much different than a big
> box...
> >
> > Back in the mid 70s, we ran a couple hundred remote terminals,
> using a
> > home-brew CICS-like system. Very tweaked assembly language, all on a
> > single 256K 360/40. How do you think that would work out on a PC
> today? :)
>
> You tell me!
>
> Those remote terminals were all handled by some sort
> of terminal controller.
>
> So to emulate that, you first need say every 20
> terminals connected to a PC running an application
> that is designed to handle the terminal interrupts
> and create a data stream and then send all the
> transactions up to the main PC. Is there such a
> thing as a bus to bus method of connecting PCs
> or do you need to go via the USB etc?
>
> > I think one major factor that separates big iron from small is
> > multi-user support. The S/360 was designed from the ground up to be
> a
> > multi programming machine, unlike the way it was forced on the PC,
> > which was designed as a single user system. Storage protection, the
> > interrupt system, parallel channels, were all designed to support
> > multi programming, and they've all been there since day 1.
>
> But which of those things exists on a modern PC
> in a sub-standard state to render it useless for
> this application?
>
> > What gives big iron the real power is the channels. A channel is
> > really a stand-alone computer. It has it's own "channel program",
> that
> > does things like seek to a specific disk cylinder, search a track
> for
> > a specific record, then read it, all while the main CPU keeps
> working
> > with a different program. All channels can be working at the same
> > time, each moving data at multi-GB rates, all while the CPU(s) keep
> on
> > trucking. Example, a modern Shark disk array (ESS) can support 16
> > channels, meaninng you can have 16 disk I/O operations going at the
> > same time. A big shop could have several Shark boxes, each with
> their
> > own, decicated, 16 channels. How would that work out on a PC? :)
>
> Ok, like you said - the channel is a stand-alone
> computer. So - can it be replaced by a stand-alone
> computer that will control a single disk and then
> via bus to bus pass a block of data up to the main
> PC?
>
> The bus isn't multi-Gbps as far as I'm aware, but
> I doubt there's too many businesses that have a
> requirement to pump multi-Gbps sustained in or
> out. Certainly no commercial environment I've ever
> worked on. And your terminal example is a trivial
> amount of data. 200 terminals would be able to
> display a new screen every second and only have a
> 1 MB/sec transfer rate requirement.
>
> I can imagine some sort of weather station requiring
> more data to be processed, but I don't know why they
> bother when the error boundary (can't even get the
> basics of rain or no rain right reliably) is so
> large that I doubt all that data is providing any
> meaningful improvement. But this is beside the point
> anyway - I'm interested in commercial environments.
>
> BFN. Paul.
>
>
> --
> Mike A Schwab, Springfield IL USA
> Where do Forest Rangers go to get away from it all?
>

[Non-text portions of this message have been removed]

•  9
  New Members

--- In hercules-390 <at> yahoogroups.com, "Rocky" <rocsystems <at> ...> wrote:
>
> Lindy,
>
>
>
> I think someone said way back the beginning of this E-mail Chain
that the
> older manuals are much easier to understand and the explanations are
better.
>
>
>
> And since you are not rewriting the complete ESA/OS or Z/OS, why
would you
> need the newer instructions at this point.
>
> After you get '"Hello World", to print on the console, what are you
going to
> give us for an encore.
>
>

One of the things that was stated at the beginning was the use of z/VM
on real hardware. VM has not supported 370 virtual machines for years
unless you ran it on a 9672 Generation 4 or earlier (not sure about
the exact generation but about 10 years ago, when the hardware stopped
supporting 370 mode) Therefore you wont be able to use SIO, TIO ect on
that platform and will have to use SSCH, ect. Unfortunately the XA
level of the Poop does not appear to be saved anywhere and even the
early ESA versions are huge.

>
> I am sure you will have plenty of mentors here to give you suggestions.
>
> This was/is a great topic and I think we are all enjoying it as
evidenced by
> the participation.
>
>
>
> My opinion is that It is "in scope" for this forum.
>
>

This email chain brings back a lot of fond memories from the early
80's when I was doing the exact same thing. My first job was at a
company called SKK where there were a lot of good and patient people
who helped and guided me, now there are email lists.

Since you have access to z/VM (work or school, whatever) there are a
lot ways to start small there. For example the HND* macros will let
you write interrupt handlers one at a time and learn how the interrupt
process works. Look at the macros in the CMS macros book.

Theres a lot to learn but it can be fun, although it may lead to crazy
ideas (like trying to rewrite MVS).

Laddie Hanus

•  9
  New Members

Lindy,

IBM is not that bad- I just checked and IPL is still in the book (at
least in POO 390 which ia am currently looking at).

SIO is not in it nor in z/390 because it is replaced by an Instrcution
with more functionality.

However CCW and CSW and CAW are still existent in an old format.

This is why someone (not me) stated somewhere that it is impossible for
someone to learn assembler today because you have to learn all the
pieces of history with it. Otherwise it is impossible to learn it.

Lindy: you are proof that he was wrong.

--
Martin
--
XML2PDF - create PDFs from within z/VSE or z/OS; more at
http://www.pi-sysprog.de

•  9
  New Members