Discussion:
Running APL\360 on OS/360-MVT 21.8F
Juergen
2013-01-04 08:38:30 UTC
Permalink
Hi Juergen,
Are you usng the same "1.00" system you recently "published"?
Sure you're not using another system with some change that
"couldn't possibly affect this" ? :)
I just tried it again from a fresh "unzip", same error,
duplicating your command inputs.
Hi Mike,

well, you're almost as insistent as Bert (@Bert: I'm sure you're reading this, so where are _YOUR_ error reports?).

So:

- Yes, it is the same system (I only created this one)
- Yes, I'm sure
- Yes, I also get the same error from a fresh unzip :-/

Well...

Due to a typo in 'SYS1.PARMLIB' member PRESRES the two volumes WORK01 and WORK02 get mounted "public" instead of "storage". So, in fact there is not a single DASD in the system that's mounted as storage. The unspecific allocation request from TSO edit requests a storage volume, which doesn't exist, and thus you get the error message.

Why doesn't this happen at my development system? The distributed system doesn't come with the starter system's DASDs, while my development system has them. The above mentioned typo gets the starter system's SYSRES volume mounted as storage (it's one line above WORK01 in the parmlib member :-/). So the only storage volume candidate is the starter system's SYSRES... and exactly this one I'm not shipping as it isn't needed for operation.

The solution is simple:

Change PRESRES member lines 4 and 5 to read

WORK01,1,0,3330,N
WORK02,1,0,3330,N

and re-IPL. Then everything will work as expected.

Cheers, Juergen
Juergen
2013-01-04 09:07:56 UTC
Permalink
I appreciate all of the efforts you have put into getting
APL\360 to run under MVT on Hercules.
I read the "README.pdf" file in the zip file -- I am curious
about why it is necessary to re-IPL MVT immediately after
shutting down APL.
Was this something you determined from some comments in
the source code, or have you seen some old "documentation"
from back in the day that described this as a requirement?
Or did you just determine this empirically, by testing?
Hi Mark,

it's both: First I realized it empirically... as you might imagine in the beginning I had APL permantly abending for various reasons and I simply restarted it always, only to receive different abends and tight loops. At some time I realized that I do get reproducible results only after a fresh IPL. Then I started searching within all documentation I could find and of course in the source too and found the information somewhere (don't remember exactly where) that APL must not be started a second time during the same MVT run and that it is recommended to re-IPL MVT as soon as possible after APL has terminated. The reason obviously is that APL doesn't cleanly terminate it's supervisor, i.e. that parts of it still remain active after APL termination, which can lead to unpredictable results.

Now, that I have it stable, testing shows:

- APL cannot be started a 2nd time. The system immediately goes into a tight loop if one tries and a Hercules "power off" is the only way to stop it.

- TSO sessions and small jobs can still be run, but the system appears to be somewhat instable. If one continues to work without having re-IPLed one will once in a while experience a hang (deadlock), which also can be resolved by a power of only.

So, to avoid that people run into these hassles I strictly recommend to re-IPL after APL termination.
Also, it occurs to me that it /should/ be possible to run
APL\360 under MVS by running it in a V=R region. This
should provide access to the advantages of MVS over MVT, as
far as the development tools, etc. available.
No, definitely not. I hoped that too in the beginning, but it's impossible. The main reason is that APL does all I/O by itself, it doesn't use the respective system services and access methods. Imagine a job in MVS, even if it's V=R, that issues it's own SIOs etc.

Cheers, Juergen
Greg Price
2013-01-05 15:35:13 UTC
Permalink
Post by Juergen
No, definitely not. I hoped that too in the beginning, but it's impossible. The main reason is that APL
does all I/O by itself, it doesn't use the respective system services and access methods. Imagine a job
in MVS, even if it's V=R, that issues it's own SIOs etc.

Well, you'd have to add disablement logic around the I/O parts.
(Does the CPU lock exist in 3.8?) How does this work in MVT?
Are there no timer pops for the OS to pre-emptively gain control
from an app which has not reached a wait state?

So, does APL\360 remain CPU-bound until all started I/Os
have been handled? What if an unsolicited interrupt comes
in while APL\360 is running causing the OS to get control?

What sort of devices are the SIOs directed to?

The 1988 VIEW program in CBT file 134 disables interrupts,
turns DAT off, and uses SIO and TIO (in the main) to perform
I/O before turning DAT on and re-anabling interrupts.

Putting the app into a V=R region means half the work is done
for you. In summary, it is not obvious to me why an app which
works under MVT cannot (be made to) work under MVS/370 with V=R.

I suppose one problem would be if the app had to run in a TSO
session, and it is hard to make an MVS TSO session run V=R.
Does all the APL\360 code run in an individual TSO region?
If so, what use of TSO facilities is made my APL\360?
A VTAM driver app which runs as a V=R started task might
be possible.

It might be non-trivial, but...
:)

Cheers,
Greg P.
Juergen
2013-01-05 17:33:51 UTC
Permalink
Post by Greg Price
Post by Juergen
No, definitely not. I hoped that too in the beginning,
but it's impossible. The main reason is that APL
does all I/O by itself, it doesn't use the respective
system services and access methods. Imagine a job
in MVS, even if it's V=R, that issues it's own SIOs etc.
Well, you'd have to add disablement logic around the I/O parts.
(Does the CPU lock exist in 3.8?) How does this work in MVT?
Are there no timer pops for the OS to pre-emptively gain control
from an app which has not reached a wait state?
So, does APL\360 remain CPU-bound until all started I/Os
have been handled? What if an unsolicited interrupt comes
in while APL\360 is running causing the OS to get control?
What sort of devices are the SIOs directed to?
The 1988 VIEW program in CBT file 134 disables interrupts,
turns DAT off, and uses SIO and TIO (in the main) to perform
I/O before turning DAT on and re-anabling interrupts.
Putting the app into a V=R region means half the work is done
for you. In summary, it is not obvious to me why an app which
works under MVT cannot (be made to) work under MVS/370 with V=R.
I suppose one problem would be if the app had to run in a TSO
session, and it is hard to make an MVS TSO session run V=R.
Does all the APL\360 code run in an individual TSO region?
If so, what use of TSO facilities is made my APL\360?
A VTAM driver app which runs as a V=R started task might
be possible.
It might be non-trivial, but...
:)
Hi Greg,

thanks for your abstract... well yes, it _might_ be possible to _make_ it run under MVS. But I'm 100% sure that it will not run without modifications that would need a prior massive code analysis effort. The goal here was to create an authentic implementation, for two reasons:

- First and foremost as a tribute to the historical importance of APL\360
- second to have a reference platform against which any modified implementations can be benchmarked and tested for regressions.

Concerning running it under MVS: It doesn't run under TSO but is a time sharing operating system on its own running as a job in an MVT region. It had originally been designed to be "IPLed" using DOS as a driver then overlaying DOS and taking control of the whole machine, which is why it uses as little operating system support as possible.

Basically one can say, running it under OS/MVT just lets MVT enough "air" that it doesn't choke.

So, I'd say, if a port to MVS is envisioned it would be better to invest effort into isolating the interpreter from the "APL OS" time sharing supervisor and get it to run directly in a TSO session, than divert to first get it to run with its supervisor in V=R.

Cheers, Juergen
Tony Harminc
2013-01-05 20:29:21 UTC
Permalink
Post by Juergen
Concerning running it under MVS: It doesn't run under TSO but is a time sharing operating system on its own running as a job in an MVT region. It had originally been designed to be "IPLed" using DOS as a driver then overlaying DOS and taking control of the whole machine, which is why it uses as little operating system support as possible.
Basically one can say, running it under OS/MVT just lets MVT enough "air" that it doesn't choke.
At the University we ran a 360/65 with APL\360 (later Sharp APL), ATS,
and CPS under MVT. This supported IIRC around 100 users, with good
response time, but no batch work. I don't know if ATS or CPS used PSW
stealing; I suspect they were BTAM apps.
Post by Juergen
So, I'd say, if a port to MVS is envisioned it would be better to invest effort into isolating the interpreter from the "APL OS" time sharing supervisor and get it to run directly in a TSO session, than divert to first get it to run with its supervisor in V=R.
A related project would be to take the APL interpreter "BLOB" from the
free IPSA PC APL, and see if it will run under the APL\360 supervisor.
It probably provides a higher level of the APL language.

Tony H.
Tony Harminc
2013-01-05 20:23:20 UTC
Permalink
Post by Juergen
Post by Juergen
No, definitely not. I hoped that too in the beginning, but it's impossible. The main reason is that APL
does all I/O by itself, it doesn't use the respective system services and access methods. Imagine a job
in MVS, even if it's V=R, that issues it's own SIOs etc.
Well, you'd have to add disablement logic around the I/O parts.
(Does the CPU lock exist in 3.8?) How does this work in MVT?
Are there no timer pops for the OS to pre-emptively gain control
from an app which has not reached a wait state?
So, does APL\360 remain CPU-bound until all started I/Os
have been handled? What if an unsolicited interrupt comes
in while APL\360 is running causing the OS to get control?
APL\360 does "PSW stealing", that is, it replaces the I/O new PSW with
its own, and then fields all I/O interrupts in its own code. Those
that are for devices it doesn't know about are sent off to the OS FLIH
by just doing an LPSW to the saved original I/O new PSW.

IPSA and STSC published a proposal for standardizing PSW stealing some
time in the 1970s, since it was being done by a number of products,
and shops were running into the problem that such products had to be
carefully shut down in reverse order from that they were started in,
or Very Bad Things would happen.
Post by Juergen
What sort of devices are the SIOs directed to?
Only the terminals, IIRC. I believe the disk I/O is done using EXCP.
But I may not RC, of course...
Post by Juergen
Putting the app into a V=R region means half the work is done
for you. In summary, it is not obvious to me why an app which
works under MVT cannot (be made to) work under MVS/370 with V=R.
It's not that it can't be done - indeed it was done by IPSA and STSC
when they ported their APL\360-based APLs to MVS. It's just that it's
a bunch of work.
Post by Juergen
I suppose one problem would be if the app had to run in a TSO
session, and it is hard to make an MVS TSO session run V=R.
Does all the APL\360 code run in an individual TSO region?
If so, what use of TSO facilities is made my APL\360?
There's no support in APL\360 for anything to do with TSO. APL\360
predates TSO by several years.

Tony H.
Gerhard Postpischil
2013-01-05 20:26:34 UTC
Permalink
Post by Greg Price
Well, you'd have to add disablement logic around the I/O parts.
(Does the CPU lock exist in 3.8?) How does this work in MVT?
Are there no timer pops for the OS to pre-emptively gain control
from an app which has not reached a wait state?
Disablement was accomplished by the now defunct SSM instruction, with a
bit mask for various interrupt types. But I'm not sure that would buy
you anything as some devices will not free the controller (or the
channel?) until an interrupt is accepted; meaning that either the APL
code would have to correctly handle interrupts from devices it doesn't
know about, or use devices only on dedicated control units and channels.
Post by Greg Price
Putting the app into a V=R region means half the work is done
for you. In summary, it is not obvious to me why an app which
works under MVT cannot (be made to) work under MVS/370 with V=R.
There are enough gotcha's to make it non-trivial, but it should be
possible, but perhaps not feasible. One approach would be to make
everything run unauthorized, and provide support code in a SPIE exit.
Another is to replace system-level code by macros, with a supporting
subroutine module that can be switched for different version of the OS.
If the I/O problem can be addressed (e.g., using EXCP) then V=R would
not be necessary.
Post by Greg Price
I suppose one problem would be if the app had to run in a TSO
session, and it is hard to make an MVS TSO session run V=R.
Does all the APL\360 code run in an individual TSO region?
If so, what use of TSO facilities is made my APL\360?
A VTAM driver app which runs as a V=R started task might
be possible.
We ran APL at the AMS service bureau in the seventies, and TSO was not
required, and we ran Wylbur instead. The only thing I remember about APL
was that it was a CPU hog that made us lots of money (we were the backup
site for a local university that used APL for class and student
scheduling).

Gerhard Postpischil
Bradford, Vermont
Bert Lindeman
2013-01-04 09:24:22 UTC
Permalink
You *are* right Juergen :-) following these threads with interest.
You're doing a heck of a job, hats off.

APL never stuck on me and was not used in the environments I worked.
And.... my time these weeks is spent mostly adding people to my family tree.

OK, you gave me enough of a stir to get looking..

Finishing with: wishing all Hercules supporters and fans: you and yours
a healthy 2013 in all aspects.

(So later I presume)

Bert
Post by Juergen
Hi Juergen,
Are you usng the same "1.00" system you recently "published"?
Sure you're not using another system with some change that
"couldn't possibly affect this" ? :)
I just tried it again from a fresh "unzip", same error,
duplicating your command inputs.
Hi Mike,
- Yes, it is the same system (I only created this one)
- Yes, I'm sure
- Yes, I also get the same error from a fresh unzip :-/
Well...
Due to a typo in 'SYS1.PARMLIB' member PRESRES the two volumes WORK01 and WORK02 get mounted "public" instead of "storage". So, in fact there is not a single DASD in the system that's mounted as storage. The unspecific allocation request from TSO edit requests a storage volume, which doesn't exist, and thus you get the error message.
Why doesn't this happen at my development system? The distributed system doesn't come with the starter system's DASDs, while my development system has them. The above mentioned typo gets the starter system's SYSRES volume mounted as storage (it's one line above WORK01 in the parmlib member :-/). So the only storage volume candidate is the starter system's SYSRES... and exactly this one I'm not shipping as it isn't needed for operation.
Change PRESRES member lines 4 and 5 to read
WORK01,1,0,3330,N
WORK02,1,0,3330,N
and re-IPL. Then everything will work as expected.
Cheers, Juergen
------------------------------------
http://groups.yahoo.com/group/hercules-390
http://www.hercules-390.org
Yahoo! Groups Links
-----
Geen virus gevonden in dit bericht.
Gecontroleerd door AVG - www.avg.com
Versie: 2013.0.2805 / Virusdatabase: 2637/5975 - datum van uitgifte: 12/20/12
Interne Virusdatabase is verouderd.
Bert Lindeman
2013-01-04 21:47:54 UTC
Permalink
OK Juergen :-)

Started install as promised.

Got up to Sample Session 1: Basic Functionality
The APL keystrokes are foreign to me.
It takes a very good concentration to correctly enter the examples.
So not now ;-)

Only thing I encountered is:
missing and "end" command after
"Prepare for APL\360 Generation"
The next step "Generate APL\360" starts with
"pds cntl"

But it's nothing is such an elaborate set of instructions.
No issues encountered, whatsoever.

My plan next: browse through manuals and try to grasp a bit of APL
knowledge.

Have a good weekend,

Bert
Juergen
2013-01-05 00:15:39 UTC
Permalink
Hi Bert,

thanks for taking a look! Yes, I'm aware of the missing END command, it's a leftover from the first preliminary distribution (I was too lazy to create a new screenshot :-/).

I'm sure you'll get infected by the APL virus once you start diving into it and detect it's power :-)

Cheers, Juergen
Post by Bert Lindeman
OK Juergen :-)
Started install as promised.
Got up to Sample Session 1: Basic Functionality
The APL keystrokes are foreign to me.
It takes a very good concentration to correctly enter the examples.
So not now ;-)
missing and "end" command after
"Prepare for APL\360 Generation"
The next step "Generate APL\360" starts with
"pds cntl"
But it's nothing is such an elaborate set of instructions.
No issues encountered, whatsoever.
My plan next: browse through manuals and try to grasp a bit of APL
knowledge.
Have a good weekend,
Bert
Mike Stramba
2013-01-04 14:13:50 UTC
Permalink
Post by Juergen
Change PRESRES member lines 4 and 5 to read
WORK01,1,0,3330,N
WORK02,1,0,3330,N
Thanks VERY MUCH for finding that !

Eh .. how do I change it ?

I tried PDS 'SYS1.PARMLIB' / TSOEDIT PRESRES.

When I try to save it, I get " DATA SET IS ALLOCATED TO ANOTHER USER OR JOB "

Mike
Post by Juergen
Hi Juergen,
Are you usng the same "1.00" system you recently "published"?
Sure you're not using another system with some change that
"couldn't possibly affect this" ? :)
I just tried it again from a fresh "unzip", same error,
duplicating your command inputs.
Hi Mike,
this, so where are _YOUR_ error reports?).
- Yes, it is the same system (I only created this one)
- Yes, I'm sure
- Yes, I also get the same error from a fresh unzip :-/
Well...
Due to a typo in 'SYS1.PARMLIB' member PRESRES the two volumes WORK01 and
WORK02 get mounted "public" instead of "storage". So, in fact there is not a
single DASD in the system that's mounted as storage. The unspecific
allocation request from TSO edit requests a storage volume, which doesn't
exist, and thus you get the error message.
Why doesn't this happen at my development system? The distributed system
doesn't come with the starter system's DASDs, while my development system
has them. The above mentioned typo gets the starter system's SYSRES volume
mounted as storage (it's one line above WORK01 in the parmlib member :-/).
So the only storage volume candidate is the starter system's SYSRES... and
exactly this one I'm not shipping as it isn't needed for operation.
Change PRESRES member lines 4 and 5 to read
WORK01,1,0,3330,N
WORK02,1,0,3330,N
and re-IPL. Then everything will work as expected.
Cheers, Juergen
Mike Stramba
2013-01-04 14:47:00 UTC
Permalink
I fixed the PRESRES thing , by copying mvtres.350 to my TurnkeyMVS,
editing it, copying it back to MVT.
Post by Mike Stramba
Post by Juergen
Change PRESRES member lines 4 and 5 to read
WORK01,1,0,3330,N
WORK02,1,0,3330,N
Thanks VERY MUCH for finding that !
Eh .. how do I change it ?
I tried PDS 'SYS1.PARMLIB' / TSOEDIT PRESRES.
When I try to save it, I get " DATA SET IS ALLOCATED TO ANOTHER USER OR JOB "
Mike
Post by Juergen
Hi Juergen,
Are you usng the same "1.00" system you recently "published"?
Sure you're not using another system with some change that
"couldn't possibly affect this" ? :)
I just tried it again from a fresh "unzip", same error,
duplicating your command inputs.
Hi Mike,
this, so where are _YOUR_ error reports?).
- Yes, it is the same system (I only created this one)
- Yes, I'm sure
- Yes, I also get the same error from a fresh unzip :-/
Well...
Due to a typo in 'SYS1.PARMLIB' member PRESRES the two volumes WORK01 and
WORK02 get mounted "public" instead of "storage". So, in fact there is not a
single DASD in the system that's mounted as storage. The unspecific
allocation request from TSO edit requests a storage volume, which doesn't
exist, and thus you get the error message.
Why doesn't this happen at my development system? The distributed system
doesn't come with the starter system's DASDs, while my development system
has them. The above mentioned typo gets the starter system's SYSRES volume
mounted as storage (it's one line above WORK01 in the parmlib member :-/).
So the only storage volume candidate is the starter system's SYSRES... and
exactly this one I'm not shipping as it isn't needed for operation.
Change PRESRES member lines 4 and 5 to read
WORK01,1,0,3330,N
WORK02,1,0,3330,N
and re-IPL. Then everything will work as expected.
Cheers, Juergen
Mike Stramba
2013-01-04 14:57:01 UTC
Permalink
How would it be fixed on a "real system" or with only mvtres available ?

Some kind of "offline" disk utility ?
Post by Mike Stramba
I fixed the PRESRES thing , by copying mvtres.350 to my TurnkeyMVS,
editing it, copying it back to MVT.
Post by Mike Stramba
Post by Juergen
Change PRESRES member lines 4 and 5 to read
WORK01,1,0,3330,N
WORK02,1,0,3330,N
Thanks VERY MUCH for finding that !
Eh .. how do I change it ?
I tried PDS 'SYS1.PARMLIB' / TSOEDIT PRESRES.
When I try to save it, I get " DATA SET IS ALLOCATED TO ANOTHER USER OR
JOB
"
Mike
Post by Juergen
Hi Juergen,
Are you usng the same "1.00" system you recently "published"?
Sure you're not using another system with some change that
"couldn't possibly affect this" ? :)
I just tried it again from a fresh "unzip", same error,
duplicating your command inputs.
Hi Mike,
this, so where are _YOUR_ error reports?).
- Yes, it is the same system (I only created this one)
- Yes, I'm sure
- Yes, I also get the same error from a fresh unzip :-/
Well...
Due to a typo in 'SYS1.PARMLIB' member PRESRES the two volumes WORK01 and
WORK02 get mounted "public" instead of "storage". So, in fact there is
not
a
single DASD in the system that's mounted as storage. The unspecific
allocation request from TSO edit requests a storage volume, which doesn't
exist, and thus you get the error message.
Why doesn't this happen at my development system? The distributed system
doesn't come with the starter system's DASDs, while my development system
has them. The above mentioned typo gets the starter system's SYSRES volume
mounted as storage (it's one line above WORK01 in the parmlib member :-/).
So the only storage volume candidate is the starter system's SYSRES... and
exactly this one I'm not shipping as it isn't needed for operation.
Change PRESRES member lines 4 and 5 to read
WORK01,1,0,3330,N
WORK02,1,0,3330,N
and re-IPL. Then everything will work as expected.
Cheers, Juergen
Ray Mullins
2013-01-04 15:05:49 UTC
Permalink
No Hercules user should be without ZZSA, an excellent stand-alone editor by
Jan Jaeger.

http://www.cbttape.org/~jjaeger/

It's even IPL-able on real iron.
Post by Mike Stramba
How would it be fixed on a "real system" or with only mvtres available ?
Some kind of "offline" disk utility ?
Post by Mike Stramba
I fixed the PRESRES thing , by copying mvtres.350 to my TurnkeyMVS,
editing it, copying it back to MVT.
Post by Mike Stramba
Post by Juergen
Change PRESRES member lines 4 and 5 to read
WORK01,1,0,3330,N
WORK02,1,0,3330,N
Thanks VERY MUCH for finding that !
Eh .. how do I change it ?
I tried PDS 'SYS1.PARMLIB' / TSOEDIT PRESRES.
When I try to save it, I get " DATA SET IS ALLOCATED TO ANOTHER USER OR
JOB
"
Mike
Post by Juergen
Hi Juergen,
Are you usng the same "1.00" system you recently "published"?
Sure you're not using another system with some change that
"couldn't possibly affect this" ? :)
I just tried it again from a fresh "unzip", same error,
duplicating your command inputs.
Hi Mike,
reading
Post by Mike Stramba
Post by Mike Stramba
Post by Juergen
this, so where are _YOUR_ error reports?).
- Yes, it is the same system (I only created this one)
- Yes, I'm sure
- Yes, I also get the same error from a fresh unzip :-/
Well...
Due to a typo in 'SYS1.PARMLIB' member PRESRES the two volumes WORK01 and
WORK02 get mounted "public" instead of "storage". So, in fact there is
not
a
single DASD in the system that's mounted as storage. The unspecific
allocation request from TSO edit requests a storage volume, which doesn't
exist, and thus you get the error message.
Why doesn't this happen at my development system? The distributed
system
Post by Mike Stramba
Post by Mike Stramba
Post by Juergen
doesn't come with the starter system's DASDs, while my development system
has them. The above mentioned typo gets the starter system's SYSRES volume
mounted as storage (it's one line above WORK01 in the parmlib member :-/).
So the only storage volume candidate is the starter system's SYSRES... and
exactly this one I'm not shipping as it isn't needed for operation.
Change PRESRES member lines 4 and 5 to read
WORK01,1,0,3330,N
WORK02,1,0,3330,N
and re-IPL. Then everything will work as expected.
Cheers, Juergen
------------------------------------
http://groups.yahoo.com/group/hercules-390
http://www.hercules-390.org
Yahoo! Groups Links
--
M. Ray Mullins
Cat Herder Software - http://www.catherdersoftware.com/
Co-manager of the z390/zCOBOL open source project
DATAGEN ™ - Generate data base and file test data
XMITVSE ™/RECVVSE ™, XMITBS2 ™/RECVBS2 ™ - XMIT format data transfer
TRKCOPY ™ for z/VSE ® and BS2000/OSD ® - low level volume maintenance
SISS-TEM ™, SIX-TEM ™, and TEMServ ™ - Total Enterprise System Management
Solutions for ADABAS access between mainframe and distributed, porting
COM-PLETE 3GL programs to CICS
Solutions for migrating to Websphere MQ
Associated with Covariant Systems, Inc.


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



------------------------------------
Mike Stramba
2013-01-04 15:23:01 UTC
Permalink
I have it.

I could have sworn it didn't work on 3350's or 3330's ..... but I just
fired it up ..... and it works !!!! ???
Post by Ray Mullins
No Hercules user should be without ZZSA, an excellent stand-alone editor by
Jan Jaeger.
http://www.cbttape.org/~jjaeger/
It's even IPL-able on real iron.
Post by Mike Stramba
How would it be fixed on a "real system" or with only mvtres available ?
Some kind of "offline" disk utility ?
Post by Mike Stramba
I fixed the PRESRES thing , by copying mvtres.350 to my TurnkeyMVS,
editing it, copying it back to MVT.
Post by Mike Stramba
Post by Juergen
Change PRESRES member lines 4 and 5 to read
WORK01,1,0,3330,N
WORK02,1,0,3330,N
Thanks VERY MUCH for finding that !
Eh .. how do I change it ?
I tried PDS 'SYS1.PARMLIB' / TSOEDIT PRESRES.
When I try to save it, I get " DATA SET IS ALLOCATED TO ANOTHER USER OR
JOB
"
Mike
Post by Juergen
Hi Juergen,
Are you usng the same "1.00" system you recently "published"?
Sure you're not using another system with some change that
"couldn't possibly affect this" ? :)
I just tried it again from a fresh "unzip", same error,
duplicating your command inputs.
Hi Mike,
reading
Post by Mike Stramba
Post by Mike Stramba
Post by Juergen
this, so where are _YOUR_ error reports?).
- Yes, it is the same system (I only created this one)
- Yes, I'm sure
- Yes, I also get the same error from a fresh unzip :-/
Well...
Due to a typo in 'SYS1.PARMLIB' member PRESRES the two volumes WORK01 and
WORK02 get mounted "public" instead of "storage". So, in fact there is
not
a
single DASD in the system that's mounted as storage. The unspecific
allocation request from TSO edit requests a storage volume, which doesn't
exist, and thus you get the error message.
Why doesn't this happen at my development system? The distributed
system
Post by Mike Stramba
Post by Mike Stramba
Post by Juergen
doesn't come with the starter system's DASDs, while my development system
has them. The above mentioned typo gets the starter system's SYSRES volume
mounted as storage (it's one line above WORK01 in the parmlib member :-/).
So the only storage volume candidate is the starter system's
SYSRES...
and
exactly this one I'm not shipping as it isn't needed for operation.
Change PRESRES member lines 4 and 5 to read
WORK01,1,0,3330,N
WORK02,1,0,3330,N
and re-IPL. Then everything will work as expected.
Cheers, Juergen
------------------------------------
http://groups.yahoo.com/group/hercules-390
http://www.hercules-390.org
Yahoo! Groups Links
--
M. Ray Mullins
Cat Herder Software - http://www.catherdersoftware.com/
Co-manager of the z390/zCOBOL open source project
DATAGEN ™ - Generate data base and file test data
XMITVSE ™/RECVVSE ™, XMITBS2 ™/RECVBS2 ™ - XMIT format data transfer
TRKCOPY ™ for z/VSE ® and BS2000/OSD ® - low level volume maintenance
SISS-TEM ™, SIX-TEM ™, and TEMServ ™ - Total Enterprise System Management
Solutions for ADABAS access between mainframe and distributed, porting
COM-PLETE 3GL programs to CICS
Solutions for migrating to Websphere MQ
Associated with Covariant Systems, Inc.
[Non-text portions of this message have been removed]
------------------------------------
http://groups.yahoo.com/group/hercules-390
http://www.hercules-390.org
Yahoo! Groups Links
------------------------------------
Mike Stramba
2013-01-04 15:58:55 UTC
Permalink
I guess it was 23xx 'sI was trying to use (with zzsa)
Post by Mike Stramba
I have it.
I could have sworn it didn't work on 3350's or 3330's ..... but I just
fired it up ..... and it works !!!! ???
Post by Ray Mullins
No Hercules user should be without ZZSA, an excellent stand-alone editor by
Jan Jaeger.
http://www.cbttape.org/~jjaeger/
It's even IPL-able on real iron.
Post by Mike Stramba
How would it be fixed on a "real system" or with only mvtres available ?
Some kind of "offline" disk utility ?
Post by Mike Stramba
I fixed the PRESRES thing , by copying mvtres.350 to my TurnkeyMVS,
editing it, copying it back to MVT.
Post by Mike Stramba
Post by Juergen
Change PRESRES member lines 4 and 5 to read
WORK01,1,0,3330,N
WORK02,1,0,3330,N
Thanks VERY MUCH for finding that !
Eh .. how do I change it ?
I tried PDS 'SYS1.PARMLIB' / TSOEDIT PRESRES.
When I try to save it, I get " DATA SET IS ALLOCATED TO ANOTHER USER OR
JOB
"
Mike
Post by Juergen
Hi Juergen,
Are you usng the same "1.00" system you recently "published"?
Sure you're not using another system with some change that
"couldn't possibly affect this" ? :)
I just tried it again from a fresh "unzip", same error,
duplicating your command inputs.
Hi Mike,
reading
Post by Mike Stramba
Post by Mike Stramba
Post by Juergen
this, so where are _YOUR_ error reports?).
- Yes, it is the same system (I only created this one)
- Yes, I'm sure
- Yes, I also get the same error from a fresh unzip :-/
Well...
Due to a typo in 'SYS1.PARMLIB' member PRESRES the two volumes
WORK01
and
WORK02 get mounted "public" instead of "storage". So, in fact there is
not
a
single DASD in the system that's mounted as storage. The unspecific
allocation request from TSO edit requests a storage volume, which doesn't
exist, and thus you get the error message.
Why doesn't this happen at my development system? The distributed
system
Post by Mike Stramba
Post by Mike Stramba
Post by Juergen
doesn't come with the starter system's DASDs, while my development system
has them. The above mentioned typo gets the starter system's SYSRES volume
mounted as storage (it's one line above WORK01 in the parmlib member :-/).
So the only storage volume candidate is the starter system's
SYSRES...
and
exactly this one I'm not shipping as it isn't needed for operation.
Change PRESRES member lines 4 and 5 to read
WORK01,1,0,3330,N
WORK02,1,0,3330,N
and re-IPL. Then everything will work as expected.
Cheers, Juergen
------------------------------------
http://groups.yahoo.com/group/hercules-390
http://www.hercules-390.org
Yahoo! Groups Links
--
M. Ray Mullins
Cat Herder Software - http://www.catherdersoftware.com/
Co-manager of the z390/zCOBOL open source project
DATAGEN ™ - Generate data base and file test data
XMITVSE ™/RECVVSE ™, XMITBS2 ™/RECVBS2 ™ - XMIT format data transfer
TRKCOPY ™ for z/VSE ® and BS2000/OSD ® - low level volume maintenance
SISS-TEM ™, SIX-TEM ™, and TEMServ ™ - Total Enterprise System Management
Solutions for ADABAS access between mainframe and distributed, porting
COM-PLETE 3GL programs to CICS
Solutions for migrating to Websphere MQ
Associated with Covariant Systems, Inc.
[Non-text portions of this message have been removed]
------------------------------------
http://groups.yahoo.com/group/hercules-390
http://www.hercules-390.org
Yahoo! Groups Links
------------------------------------
Mike Stramba
2013-01-04 16:39:37 UTC
Permalink
Is there any reason that the BALLOON, APL360 jobs would not run from
SYS1.PROCLIB ?

I.e. is there a technical reason, why running it from TSO / a "user
logon" makes any difference ?

.. And therefore could be started from the master console ..... S
BALLOON ...... S APL360 ?

btw I'm not criticizing the current design. I'm (obviously) a
"mainframe newb", just wondering about the above.

Mike
Post by Mike Stramba
I guess it was 23xx 'sI was trying to use (with zzsa)
Post by Mike Stramba
I have it.
I could have sworn it didn't work on 3350's or 3330's ..... but I just
fired it up ..... and it works !!!! ???
Post by Ray Mullins
No Hercules user should be without ZZSA, an excellent stand-alone editor by
Jan Jaeger.
http://www.cbttape.org/~jjaeger/
It's even IPL-able on real iron.
Post by Mike Stramba
How would it be fixed on a "real system" or with only mvtres available ?
Some kind of "offline" disk utility ?
Post by Mike Stramba
I fixed the PRESRES thing , by copying mvtres.350 to my TurnkeyMVS,
editing it, copying it back to MVT.
Post by Mike Stramba
Post by Juergen
Change PRESRES member lines 4 and 5 to read
WORK01,1,0,3330,N
WORK02,1,0,3330,N
Thanks VERY MUCH for finding that !
Eh .. how do I change it ?
I tried PDS 'SYS1.PARMLIB' / TSOEDIT PRESRES.
When I try to save it, I get " DATA SET IS ALLOCATED TO ANOTHER
USER
OR
JOB
"
Mike
Post by Juergen
Hi Juergen,
Are you usng the same "1.00" system you recently "published"?
Sure you're not using another system with some change that
"couldn't possibly affect this" ? :)
I just tried it again from a fresh "unzip", same error,
duplicating your command inputs.
Hi Mike,
reading
Post by Mike Stramba
Post by Mike Stramba
Post by Juergen
this, so where are _YOUR_ error reports?).
- Yes, it is the same system (I only created this one)
- Yes, I'm sure
- Yes, I also get the same error from a fresh unzip :-/
Well...
Due to a typo in 'SYS1.PARMLIB' member PRESRES the two volumes
WORK01
and
WORK02 get mounted "public" instead of "storage". So, in fact there is
not
a
single DASD in the system that's mounted as storage. The unspecific
allocation request from TSO edit requests a storage volume, which doesn't
exist, and thus you get the error message.
Why doesn't this happen at my development system? The distributed
system
Post by Mike Stramba
Post by Mike Stramba
Post by Juergen
doesn't come with the starter system's DASDs, while my development system
has them. The above mentioned typo gets the starter system's SYSRES volume
mounted as storage (it's one line above WORK01 in the parmlib
member
:-/).
So the only storage volume candidate is the starter system's
SYSRES...
and
exactly this one I'm not shipping as it isn't needed for operation.
Change PRESRES member lines 4 and 5 to read
WORK01,1,0,3330,N
WORK02,1,0,3330,N
and re-IPL. Then everything will work as expected.
Cheers, Juergen
------------------------------------
http://groups.yahoo.com/group/hercules-390
http://www.hercules-390.org
Yahoo! Groups Links
--
M. Ray Mullins
Cat Herder Software - http://www.catherdersoftware.com/
Co-manager of the z390/zCOBOL open source project
DATAGEN ™ - Generate data base and file test data
XMITVSE ™/RECVVSE ™, XMITBS2 ™/RECVBS2 ™ - XMIT format data transfer
TRKCOPY ™ for z/VSE ® and BS2000/OSD ® - low level volume maintenance
SISS-TEM ™, SIX-TEM ™, and TEMServ ™ - Total Enterprise System Management
Solutions for ADABAS access between mainframe and distributed, porting
COM-PLETE 3GL programs to CICS
Solutions for migrating to Websphere MQ
Associated with Covariant Systems, Inc.
[Non-text portions of this message have been removed]
------------------------------------
http://groups.yahoo.com/group/hercules-390
http://www.hercules-390.org
Yahoo! Groups Links
------------------------------------
Mike Stramba
2013-01-04 17:12:06 UTC
Permalink
Is there a way to abort a function-editing session in APL ?

The only thing I've found in the manuals is that sh-G ("down
triangle") ends / saves the function.

I tried as a guess ATT (ctr-a), but it doesn't seem to work

Mike
Post by Mike Stramba
Is there any reason that the BALLOON, APL360 jobs would not run from
SYS1.PROCLIB ?
I.e. is there a technical reason, why running it from TSO / a "user
logon" makes any difference ?
.. And therefore could be started from the master console ..... S
BALLOON ...... S APL360 ?
btw I'm not criticizing the current design. I'm (obviously) a
"mainframe newb", just wondering about the above.
Mike
Post by Mike Stramba
I guess it was 23xx 'sI was trying to use (with zzsa)
Post by Mike Stramba
I have it.
I could have sworn it didn't work on 3350's or 3330's ..... but I just
fired it up ..... and it works !!!! ???
Post by Ray Mullins
No Hercules user should be without ZZSA, an excellent stand-alone
editor
by
Jan Jaeger.
http://www.cbttape.org/~jjaeger/
It's even IPL-able on real iron.
Post by Mike Stramba
How would it be fixed on a "real system" or with only mvtres
available
?
Some kind of "offline" disk utility ?
Post by Mike Stramba
I fixed the PRESRES thing , by copying mvtres.350 to my TurnkeyMVS,
editing it, copying it back to MVT.
Post by Mike Stramba
Post by Juergen
Change PRESRES member lines 4 and 5 to read
WORK01,1,0,3330,N
WORK02,1,0,3330,N
Thanks VERY MUCH for finding that !
Eh .. how do I change it ?
I tried PDS 'SYS1.PARMLIB' / TSOEDIT PRESRES.
When I try to save it, I get " DATA SET IS ALLOCATED TO ANOTHER
USER
OR
JOB
"
Mike
Post by Juergen
Hi Juergen,
Are you usng the same "1.00" system you recently "published"?
Sure you're not using another system with some change that
"couldn't possibly affect this" ? :)
I just tried it again from a fresh "unzip", same error,
duplicating your command inputs.
Hi Mike,
reading
Post by Mike Stramba
Post by Mike Stramba
Post by Juergen
this, so where are _YOUR_ error reports?).
- Yes, it is the same system (I only created this one)
- Yes, I'm sure
- Yes, I also get the same error from a fresh unzip :-/
Well...
Due to a typo in 'SYS1.PARMLIB' member PRESRES the two volumes
WORK01
and
WORK02 get mounted "public" instead of "storage". So, in fact
there
is
not
a
single DASD in the system that's mounted as storage. The unspecific
allocation request from TSO edit requests a storage volume, which doesn't
exist, and thus you get the error message.
Why doesn't this happen at my development system? The distributed
system
Post by Mike Stramba
Post by Mike Stramba
Post by Juergen
doesn't come with the starter system's DASDs, while my development system
has them. The above mentioned typo gets the starter system's
SYSRES
volume
mounted as storage (it's one line above WORK01 in the parmlib
member
:-/).
So the only storage volume candidate is the starter system's
SYSRES...
and
exactly this one I'm not shipping as it isn't needed for operation.
Change PRESRES member lines 4 and 5 to read
WORK01,1,0,3330,N
WORK02,1,0,3330,N
and re-IPL. Then everything will work as expected.
Cheers, Juergen
------------------------------------
http://groups.yahoo.com/group/hercules-390
http://www.hercules-390.org
Yahoo! Groups Links
--
M. Ray Mullins
Cat Herder Software - http://www.catherdersoftware.com/
Co-manager of the z390/zCOBOL open source project
DATAGEN ™ - Generate data base and file test data
XMITVSE ™/RECVVSE ™, XMITBS2 ™/RECVBS2 ™ - XMIT format data transfer
TRKCOPY ™ for z/VSE ® and BS2000/OSD ® - low level volume maintenance
SISS-TEM ™, SIX-TEM ™, and TEMServ ™ - Total Enterprise System Management
Solutions for ADABAS access between mainframe and distributed, porting
COM-PLETE 3GL programs to CICS
Solutions for migrating to Websphere MQ
Associated with Covariant Systems, Inc.
[Non-text portions of this message have been removed]
------------------------------------
http://groups.yahoo.com/group/hercules-390
http://www.hercules-390.org
Yahoo! Groups Links
------------------------------------
Gerhard Postpischil
2013-01-04 19:58:31 UTC
Permalink
Post by Mike Stramba
How would it be fixed on a "real system" or with only mvtres available ?
It depends on the sophistication of the installation. The simplest way
would be to run an IEBUPDTE (line number editing), or it or IEBGENER for
a complete replacement (using DISP=SHR and ensuring nobody else tries to
alter the PDS in the interim, and that it doesn't get extra extents.).
If the PDS is closed after your job runs, it can reset DS1LSTAR, which
makes for other problems; so an immediate IPL, without shutdown, after
verifying your change, prevents the DSCB from getting set back.

www.cbttape.org contains lots of submissions for non-IBM solutions. It
is possible to inhibit the ENQ interlock, another is to make a renamed
copy of the data set, edit that, then ZAP the VTOC to switch data set
names (should also recatalog after IPL). For OS/360, after SMF was
introduced, I had an IEFUSI exit that accepted a special ACCT permitting
ENQ bypass or running in key 0.



Gerhard Postpischil
Bradford, Vermont
Juergen
2013-01-05 00:17:45 UTC
Permalink
Hi Gerhard,

thanks for replying! I read it only after replying the same in a less sophisticated manner ;-)

Cheers, Juergen
Post by Gerhard Postpischil
Post by Mike Stramba
How would it be fixed on a "real system" or with only mvtres available ?
It depends on the sophistication of the installation. The simplest way
would be to run an IEBUPDTE (line number editing), or it or IEBGENER for
a complete replacement (using DISP=SHR and ensuring nobody else tries to
alter the PDS in the interim, and that it doesn't get extra extents.).
If the PDS is closed after your job runs, it can reset DS1LSTAR, which
makes for other problems; so an immediate IPL, without shutdown, after
verifying your change, prevents the DSCB from getting set back.
www.cbttape.org contains lots of submissions for non-IBM solutions. It
is possible to inhibit the ENQ interlock, another is to make a renamed
copy of the data set, edit that, then ZAP the VTOC to switch data set
names (should also recatalog after IPL). For OS/360, after SMF was
introduced, I had an IEFUSI exit that accepted a special ACCT permitting
ENQ bypass or running in key 0.
Gerhard Postpischil
Bradford, Vermont
Juergen
2013-01-04 23:58:29 UTC
Permalink
Post by Mike Stramba
How would it be fixed on a "real system" or with only
mvtres available ?
Some kind of "offline" disk utility ?
Post by Mike Stramba
I fixed the PRESRES thing , by copying mvtres.350 to
my TurnkeyMVS, editing it, copying it back to MVT.
Post by Juergen
Change PRESRES member lines 4 and 5 to read
WORK01,1,0,3330,N
WORK02,1,0,3330,N
Hi Mike,

glad your method to edit it worked. Generally I don't recommend writing on MVT DASD from MVS, as there might be backward compatibility problems. Although ZZSA of course works, I consider such a thing as a last resort, for example when the system doesn't IPL any more...

The easiest (and probably most safe) way to do it is just from the running system: Open the member in TSO edit, modify it, save it in one of your private libraries, then use IEBGENER (with DISP=SHR on SYSUT2) to copy it back into parmlib.

Cheers, Juergen
Mike Stramba
2013-01-05 01:12:07 UTC
Permalink
Post by Juergen
The easiest (and probably most safe) way to do it is just from the running
system: Open the member in TSO edit, modify it, save it in one of your
private libraries, then use IEBGENER (with DISP=SHR on SYSUT2) to copy it
back into parmlib.
Why would an IEBGENER copy work, while EDIT / SAVE directly does not ?

Is it because EDIT is not / (can't ?) opening the file as SHR ?

Mike
Post by Juergen
Post by Mike Stramba
How would it be fixed on a "real system" or with only
mvtres available ?
Some kind of "offline" disk utility ?
Post by Mike Stramba
I fixed the PRESRES thing , by copying mvtres.350 to
my TurnkeyMVS, editing it, copying it back to MVT.
Post by Juergen
Change PRESRES member lines 4 and 5 to read
WORK01,1,0,3330,N
WORK02,1,0,3330,N
Hi Mike,
glad your method to edit it worked. Generally I don't recommend writing on
MVT DASD from MVS, as there might be backward compatibility problems.
Although ZZSA of course works, I consider such a thing as a last resort, for
example when the system doesn't IPL any more...
The easiest (and probably most safe) way to do it is just from the running
system: Open the member in TSO edit, modify it, save it in one of your
private libraries, then use IEBGENER (with DISP=SHR on SYSUT2) to copy it
back into parmlib.
Cheers, Juergen
Juergen
2013-01-05 00:07:09 UTC
Permalink
Post by Mike Stramba
Is there any reason that the BALLOON, APL360 jobs would
not run from SYS1.PROCLIB ?
I.e. is there a technical reason, why running it from TSO /
a "user logon" makes any difference ?
.. And therefore could be started from the master console
..... S BALLOON ...... S APL360 ?
Hi Mike,

of course the BALLOON could be run as a started task.

But APL\360 doesn't run that way, as there is no easy way to set the initial priority when one doesn't have a jobcard available. One could create a started task running IEBGENER, which in turn would copy the job to HASP's internal reader. It was just lazyness on my side not to do that kind of nice to have stuff, given the vast amount of other thing that had to be done.

Cheers, Juergen
Mike Stramba
2013-01-05 01:36:33 UTC
Permalink
Post by Juergen
But APL\360 doesn't run that way, as there is no easy way to set the initial
priority when one doesn't have a jobcard available. One could create a
A glance / search through the source code for "priority" seems to
indicate that it's important :)

Like this stuff ? :

So is PRTY=13, acting on "TCBMERE - ALWAYS AT THE LIMIT PRIORITY." ?

* APL (OS) RUNS WITH TWO TCBS.. MFT 02860000
* TCBMERE - ALWAYS AT THE LIMIT PRIORITY. 02990000
* TCBFILLE - ALTERNATES BETWEEN THE LIMIT PRIORITY AND ZERO. 03120000
* SEE CODE IN APLSUP AT APLSETHI, APLSETLO. 03250000

* KEEP DISPATCHING PRIORITY OF DAUGHTER SLIGHTLY LOWER THAN 18070000
* MOTHER SO THAT MOTHER WILL ALWAYS BE RUN IN PREFERENCE. 18200000

* 2. RAISES AND LOWERS THE PRIORITY OF THE DAUGHTER TASK 31980000
* ON REQUEST FROM APLSUP. 32110000
* THIS IS DONE HERE RATHER THAN IN APLSUP TO ELIMINATE THE 32240000
* POSSIBILITY OF A TASK SWITCH WHILE IN APLSUP. A TASK SWITCH 32370000
* MAY OCCUR IN MOTHER. 32500000
Post by Juergen
Post by Mike Stramba
Is there any reason that the BALLOON, APL360 jobs would
not run from SYS1.PROCLIB ?
I.e. is there a technical reason, why running it from TSO /
a "user logon" makes any difference ?
.. And therefore could be started from the master console
..... S BALLOON ...... S APL360 ?
Hi Mike,
of course the BALLOON could be run as a started task.
But APL\360 doesn't run that way, as there is no easy way to set the initial
priority when one doesn't have a jobcard available. One could create a
started task running IEBGENER, which in turn would copy the job to HASP's
internal reader. It was just lazyness on my side not to do that kind of nice
to have stuff, given the vast amount of other thing that had to be done.
Cheers, Juergen
Juergen
2013-01-05 00:11:44 UTC
Permalink
Post by Mike Stramba
Is there a way to abort a function-editing session in APL ?
The only thing I've found in the manuals is that sh-G ("down
triangle") ends / saves the function.
I tried as a guess ATT (ctr-a), but it doesn't seem to work
Shift-G (Nabla) is the only way to start and end the function editor, besides heavier stuff that would involve bouncing the user. But why would you want to use something else?

Cheers, Juergen
Mike Stramba
2013-01-05 01:27:16 UTC
Permalink
Post by Juergen
Shift-G (Nabla) is the only way to start and end the function editor,
besides heavier stuff that would involve bouncing the user. But why would
you want to use something else?
As I wrote, to *abort* the edit.

Sloppy typist that I am, and I'm still trying to figure out how the
backspace / correction thing works :)

Mike
Post by Juergen
Post by Mike Stramba
Is there a way to abort a function-editing session in APL ?
The only thing I've found in the manuals is that sh-G ("down
triangle") ends / saves the function.
I tried as a guess ATT (ctr-a), but it doesn't seem to work
Shift-G (Nabla) is the only way to start and end the function editor,
besides heavier stuff that would involve bouncing the user. But why would
you want to use something else?
Cheers, Juergen
Juergen
2013-01-05 01:18:10 UTC
Permalink
Post by Mike Stramba
Post by Juergen
The easiest (and probably most safe) way to do it is
just from the running
system: Open the member in TSO edit, modify it, save it
in one of your private libraries, then use IEBGENER
(with DISP=SHR on SYSUT2) to copy it back into parmlib.
Why would an IEBGENER copy work, while EDIT / SAVE
directly does not ?
Is it because EDIT is not / (can't ?) opening the file
as SHR ?
Exactly: EDIT always opens as SHR for reading but as OLD for writing.

Cheers, Juergen
Juergen
2013-01-05 09:36:47 UTC
Permalink
Post by Mike Stramba
Post by Juergen
But APL\360 doesn't run that way, as there is no easy
way to set the initial priority when one doesn't have
a jobcard available. One could create a
A glance / search through the source code for "priority"
seems to indicate that it's important :)
So is PRTY=13, acting on
"TCBMERE - ALWAYS AT THE LIMIT PRIORITY." ?
exactly...

I didn't analyse this in full depth, but gave running it as a started task a try in the very beginning. This led to an instable system typically abending or looping shortly after initialization.

All documentation that can be found mentions the importance of a correct priority setting. From my point of view a bit mystic on a system on which no one else competes for resources, but in general those developers new what they did. Bottomline for me is, to not ignore the sparse recommendations relevant for MVT found scattered around source and documentation (remember: most sysprog type doc is for the DOS version...).

Nonetheless: If you want to start it from the console create an IEBGENER submission wrapper. The should work without any problems.

Cheers, Juergen
Gerhard Postpischil
2013-01-05 20:41:18 UTC
Permalink
Post by Juergen
All documentation that can be found mentions the importance of a
correct priority setting. From my point of view a bit mystic on a
system on which no one else competes for resources, but in general
those developers new what they did. Bottomline for me is, to not
ignore the sparse recommendations relevant for MVT found scattered
around source and documentation (remember: most sysprog type doc is
for the DOS version...).
Perhaps I'm missing something. If priority is the only issue, why can't
it be a start job? I use EXEC ... DPRTY=(15,13) on one of my jobs, and
only JES and GTF are higher (at 15,15). (15,13) appears to be the most
frequent value for STCs, with only TCAM being lower. So you could use
(15,14).

Gerhard Postpischil
Bradford, Vermont
Juergen
2013-01-06 10:36:15 UTC
Permalink
Post by Gerhard Postpischil
Post by Juergen
All documentation that can be found mentions the importance
of a correct priority setting. From my point of view a bit
mystic on a system on which no one else competes for resources,
but in general those developers new what they did. Bottomline
for me is, to not ignore the sparse recommendations relevant
for MVT found scattered around source and documentation
(remember: most sysprog type doc is for the DOS version...).
Perhaps I'm missing something. If priority is the only issue,
why can't it be a start job? I use EXEC ... DPRTY=(15,13)
on one of my jobs, and only JES and GTF are higher (at 15,15).
(15,13) appears to be the most frequent value for STCs, with
only TCAM being lower. So you could use (15,14).
Hi Gerhard,

you're right, of course. Sometimes it doesn't harm to review conclusions made in an early stage later on...

As I mentioned I did some testing running it as a started task very early on. I then of course tried using DPRTY also, only to note that I didn't get it running. But the point is that during that stage it wasn't stable when running it as a job neither and my motivation to test running it as a started task was to get any dynamic priority handling possibly done by HASP out of the way to see if that would help (in some documentation I found information on possible conflicts between APL\360's internal priority handling and HASP's dynamic performance groups).

When then the result running as a started task was even worse then when running it as a job under HASP I abandoned the idea.

Reviewed now, probably most problems at that stage came from APL running into tight loops caused by our terminal emulations not behaving correctly, invalid region location or invalid disk structures (this was even before I managed to create the first handcrafted "empty" disk layout).

Well, of course those tight loops are the tighter the higher the dispatching priority is :-))) which explains why I had those bad results when trying to run it as a started task (and btw. also as a job under an OS intiator without HASP being in the game): HASP ignores the PRTY parameter on the jobcard, while it is honoured when running under and OS initiator as well as DPRTY is honoured when running it as an STC!

Ouch!

Coming to that conclusion I now tried running it as an STC again: And, as expected, it sails smoothly ;-)

Of course I still have to verify stability on a longer run. But I don't expect surprises: Given the above thoughts it should work equally well or better now than when running under HASP, as priority handling should now work correctly.

I'm particularily curious whether the consistently missing midnight date advance action (most probably a timing/priority issue) will now get catched...

So, thanks for pointing me back at this again!

Cheers, Juergen
Juergen
2013-01-05 09:55:10 UTC
Permalink
Post by Mike Stramba
Post by Juergen
Shift-G (Nabla) is the only way to start and end the
function editor, besides heavier stuff that would
involve bouncing the user. But why would you want to
use something else?
As I wrote, to *abort* the edit.
Sloppy typist that I am, and I'm still trying to figure out
how the backspace / correction thing works :)
Ah, you mean how to abort without saving changes... well that's a totally different story: The savable entity with APL is the workspace, not the function. During exection of your session the whole active workspace is in core (or on swap DASD) and evey change you make is life, there is no saved version of the function. Going back to a previously save version means reloading the entire workspace, which brings it back to the state when you last saved it.

So, if you're a sloppy typist, work as follows:

- Issue )SAVE _before_ editing a function.
- Edit the function.
- If you edited it to death exit regularily (using Nabla) then issue a )LOAD command to restore the workspace to the state before editing the function.

Btw.: A comprehensive description of overstriking and erasure can be found in the User's Manual on page 3.3 and the function editor is described on page 3.16 (note that with the 1052 emulation "backspace" is assigned to the backspace key of your keyboard, while linefeed is assigned to shift-X).

Cheers, Juergen
halfmeg
2013-01-05 21:26:53 UTC
Permalink
Post by Mike Stramba
Is there a way to abort a function-editing session in APL ?
The only thing I've found in the manuals is that sh-G ("down
triangle") ends / saves the function.
I tried as a guess ATT (ctr-a), but it doesn't seem to work
With a function definition open you can't do a ")save" but you can do a ")clear" and then load it back in. The changes prior to the last save will be gone so as Juergen mentioned you can save quite often.

Phil
Juergen
2013-01-06 14:00:14 UTC
Permalink
The first job submitted, named BALLOON, is a place holder. For
some weird (i.e. not yet analyzed) reason APL\360 refuses to work
when loaded into high core (where high starts at around 7500K).
I'm afraid what we're running into here may be a signed halfword
addressing problem, similar to what kept MVT time sharing regions
from working if the region had addresses greater than 8MB.
LH Rx,high-order-16-bits-of-address
SLL Rx,8
For an address of X'800000', Rx should contain X'00800000', but
instead ended up containing X'FF800000' because what LH was treating
as a sign bit was being propagated to the left. If you reduce
Hercules MAINSIZE to 8, you may get other errors but APL works,
or at least I can get the same sign-on errors without hanging MVT.
Don't have a magic answer about how to find what might be causing
this with APL.
Hi Kevin,

coming back to that 8 MB issue: I just did a bit of stress testing APL\360 and used my newly created mini OPFNS workspace to have a look behind the scenes. During this I recognized an effect showing that APL\360 wasn't designed to run above the 8 MB line. It's not exactly of the kind you mention above but quite similar:

One of my test setups was as follows:

9 users signed on, the operator and my work user, plus seven users stressing the system by constantly running my sine plot function in different time intervalls between 0.1 and 1 seconds.

Purpose was a long term console stability test (due to the sine plot output), a bit of CPU load for the computations, and last but not least a swap test: Having 4 memory slots for APL users sysgen'ed 7 active users (plus myself poking around in core) will clearly force swapping to occur.

The main result: Everything 100% stable, even when my wife hit the power button of my PC during vacuuming, disconnecting all the sessions at once from the server sitting remotely in our data center, APL\360 remained cool and responsive :-).

The side observation: The following table shows per column a snapshot of the PERCORE address fields in the PERTERM control blocks of all 16 terminals in the system. A terminal has a valid PERCORE block assigned if and only if it's associated workspace currently is swapped in. So, with the above scenario, there always must be 4 valid PERCORE addresses and the rest must be invalid. Now look, how they distinguish it:

800000 800000 800000 800000 800000 800000 800000 800000 800000
800000 800000 800000 800000 800000 800000 800000 800000 800000
800000 800000 800000 800000 800000 800000 800000 800000 800000
800000 800000 800000 800000 800000 800000 800000 800000 800000
6B5510 6B5508 6B5508 6B5508 6B5508 6B5508 6B5508 6B5508 6B5508
6B5520 6B5520 6B5520 6B5520 6B5520 6B5520 6B5520 6B5520 6B5520
805510 6B5510 805508 805508 805508 805508 805508 805508 6B5510
805508 805508 805508 6B5510 805508 805508 805508 805508 805508
800000 800000 800000 800000 800000 800000 800000 800000 800000
800000 800000 800000 800000 800000 800000 800000 800000 800000
800000 800000 800000 800000 800000 800000 800000 800000 800000
805510 805510 805510 805510 805510 805510 805510 805510 805510
805508 805508 6B5510 805508 805508 805508 805508 805508 805508
805508 805508 805508 805508 6B5510 6B5510 6B5510 805508 805508
6B5518 6B5518 6B5518 6B5518 6B5518 6B5518 6B5518 6B5518 6B5518
6B5508 805508 805508 805508 805508 805508 805508 6B5510 805508

Valid and invalid is distinguished by the high order bit of the 24-bit address, meaning that addresses above 7FFFFF will always be considered being invalid :-)

So, I considered the region location dependency as "works as designed": It is a permanent restriction that the APL\360 region has to be located below the 8-MB line.

Cheers, Juergen
Gerhard Postpischil
2013-01-07 19:05:18 UTC
Permalink
LH Rx,high-order-16-bits-of-address
SLL Rx,8
For an address of X'800000', Rx should contain X'00800000', but
instead ended up containing X'FF800000' because what LH was treating
as a sign bit was being propagated to the left. If you reduce
Hercules MAINSIZE to 8, you may get other errors but APL works,
or at least I can get the same sign-on errors without hanging MVT.
I noticed that all the table entries shown were non-zero. Unless
something else is going on, the code could be replaced by an ICM/BNP/N
(valid on 370; macro on F assembler?) and using zero for an unassigned slot?



Gerhard Postpischil
Bradford, Vermont
Juergen
2013-01-07 20:04:32 UTC
Permalink
Post by Gerhard Postpischil
LH Rx,high-order-16-bits-of-address
SLL Rx,8
For an address of X'800000', Rx should contain X'00800000', but
instead ended up containing X'FF800000' because what LH was
treating as a sign bit was being propagated to the left.
If you reduce Hercules MAINSIZE to 8, you may get other
errors but APL works, or at least I can get the same sign-on
errors without hanging MVT.
I noticed that all the table entries shown were non-zero. Unless
something else is going on, the code could be replaced by
an ICM/BNP/N (valid on 370; macro on F assembler?) and using
zero for an unassigned slot?
Hi Gerhard,

don't get me wrong: I didn't say that it isn't possible to change the code to _make_ it work (for example, the whole high order _byte_ of these addresses is completely unused), I simply stated the fact that APL\360 had not been designed to run above the 8 MB line.

The focus at this stage really is an authentic implementation, with absolutely no changes made to the original APL\360 code. I even withstood the temptation to remove that silly Shift-X, Shift-Z, backspace, newline ambiguity in the 1052-7 implementation, although this would have meant a simple two byte code change only.

And btw., concerning the 8 MB line: When they did it in the PERTERMs this way they most probably did it in many other locations too... so the change would presumably be way more complex than it seems on first sight. On the other hand, there would be no real point to fix this: Given my balloon placeholder trick APL\360 can easily be forced below the line, or else MVT could just be run with 8 MB or less core...

One thing still might be interesting to check out: If one wanted to run with x-large workspaces, for example 3 MB instead of the default 36000 byte, 4 slots would occupy 12 MB and the APL code would be forced below the line in any case. Question is, what the largest workspace size is that could feasibly be used and whether APL would be able to address memory slots above the 8 MB line? That question is indendent from the PERTERM and PERCORE locations as these always sit below the workspace slots. But then other questions come up immediately, like: How would the garbage collector behave with x-large workspaces, etc... well, I don't think that I want to dig into this for now.

Cheers, Juergen
Gerhard Postpischil
2013-01-07 22:17:36 UTC
Permalink
Post by Juergen
don't get me wrong: I didn't say that it isn't possible to change the
code to _make_ it work (for example, the whole high order _byte_ of
these addresses is completely unused), I simply stated the fact that
APL\360 had not been designed to run above the 8 MB line.
I just mentioned that as appearing to require a minimal amount of change
in the code. Finding it is another problem... <g>

It does bring to mind an MVT change we picked up at SHARE in the
mid-seventies. It provides storage "fencing" allowing the installation
to create virtual partitions, and directing jobs to those partitions
dependent on region size (or perhaps job class?); the intent was to
minimize job scheduling delays due to storage fragmentation, but it
would seem ideal to force your APL job below 8MB. I have no idea whether
Sam Golob still has the old OS/360 SHARE tapes.
Post by Juergen
The focus at this stage really is an authentic implementation, with
absolutely no changes made to the original APL\360 code. I even
withstood the temptation to remove that silly Shift-X, Shift-Z,
backspace, newline ambiguity in the 1052-7 implementation, although
this would have meant a simple two byte code change only.
I'm quite aware of the distinction between a quick and dirty
implementation with minimal changes, and a long range effort. In
general, following the principle of least astonishment, changes can be
made if they don't affect existing work or work habits.

Gerhard Postpischil
Bradford, Vermont
afgcons
2013-01-08 19:46:52 UTC
Permalink
Post by Juergen
don't get me wrong: I didn't say that it isn't possible to change the
code to _make_ it work (for example, ...
It does bring to mind an MVT change we picked up at SHARE in the
mid-seventies. It provides storage "fencing" allowing the installation
to create virtual partitions, and directing jobs to those partitions ...
IMO, OS/MFT, where jobs are assigned to fixed, predefined partitions, looks like a better APL\360 host to me. MFT is easier to set up and runs leaner. MFT was "the poor men's MVT" because it needed anywhere from 128...256K less *core* than MVT would need for the same corporate workload.

Except for anything using an IKJ macro/feature (TSO ATTACH / DETACH) and a few special MVT-only options (like CHECKPOINT/RESTART), if it ran in an MVT region it also ran mighty fine in an MFT partition.

Andreas Geissbuehler
Thomas
2013-01-07 10:41:42 UTC
Permalink
After the many postings regarding running the APL\360 code under MVT I decided to look at the code in the context of moving the code to MVS as I have had some experience in refurbishing old code.

Firstly, looking at the online component of APL\360.

The online code makes minimal use of OS/360 and where it does use OS/360 services all of the expected integrity associated with OS/360 is circumvented by the code. The only exception being the workspace interpreter.

All OS APL/360 code runs in Key 0 Supervisor state except when the interpreter is dispatched with the region user key to interpret the users workspace code which is resident in storage set to the region user key. System/360 storage protection is used to prevent errors in APL\360 user programs that would corrupt APL\360 code or other resident workspaces. The storage keys and PSW key are set without the use of any system services.

DASD I/O
APL\360 uses EXCP for all DASD processing however the dataset integrity of EXCP processing is circumvented. The DEB file mask for each dataset is set to zero allowing embedded cylinder SEEKs in CCW strings. The CCW strings used by the code do have embedded SEEKs with the CCHH DASD address calculated by the code. Therefore any error in calculating the provided CCHH may result in I/O outside of the extents of a SWAP or LIBRARY dataset. This will not be prevented by the MVT I/O Supervisor and could result in corruption of other datasets on the volume (including the VTOC).

APL\360 uses PCI, CE and Abnormal End (XE) Appendages for control of the I/O to the SWAP and LIBRARY datasets. The provided Appendage exits are not discreetly coded routines isolated for ease of understanding and maintenance but are in fact dummy routines which pass control directly into the complex APL\360 control code running disabled in Key 0 Supervisor state.

SWAP and LIBRARY dataset device characteristics are obtained from the DEVTYPE macro. They may be allocated on 2311, 2314, 3330 or any DASD device supported by MVT however not to any device with a track size exceeding 14000 as that is the size of the DASD I/O area allocated in the IM CSECT in APLSSINI. RPS Support is included in the DASD driving code and not identified in the source as a retro fit/enhancement. An interesting aside is that the APL\360 source code as distributed has a date 05/11/70 whereas IBM announced 3330s in Jun 1970 so 3330s must have been generally available inside the IBM Labs for some time before Customer Announcement.

Terminal I/O
APL\360 does not use OS/360 for I/O to the terminal devices. Therefore no OS/360 UCBs are required or used to drive the terminals. No OS/360 Access Method code is used. I/O to the terminals is driven directly by SIO instructions initiating CCWs strings built and updated by AP\360. Extensive use is made of PCI interrupts to update running channel programs to manage the buffer pool. To implement this method of I/O, on startup, the I/O New PSW is replaced with a PSW passing control directly to APL\360. All I/O interrupts are received by APL\360 where the interrupting device address is inspected and non APL\360 terminal interrupts are passed to the MVT I/O Supervisor for processing. All terminal I/O error processing is implemented in the APL\360 terminal control routines. Due to the characteristics of start/stop terminal hardware and unique characteristics of each terminal type the terminal I/O driving code and CCW manipulation code is closely integrated with the applications parsing and processing code.

The code is designed to run a significant number of terminals to support a large user population in competition for computer resources executing the APL\360 interpreter so it has been implemented using an interrupt driven structure. Running disabled during terminal I/O would not be possible due to the PCI driven code managing the buffer pool.

Timer Processing
Branch entry points are used to enter internal MVT Timer code for finer granular control of timer services.

PSW Formats
The code manipulates BC Mode PSWs to dispatch various code routines. This code would not function correctly with EC Mode PSWs

24 Bit Addressing Violation
The excellent diagnostic work by Juergen has identified the problem with APL\360 failing when it is running above the 8MB line due to use of hi-order flag bits in a 24 bit address field. This will make a migration to MVS very difficult.

Batch Utility Component
The APL\360 batch utility code is compliant with standard OS/360 APIs except that the DEB file mask is set to zero to allow cylinder SEEKs in CCW chains. The I/O Appendages used in the online component are not loaded for use during batch processing. Tape I/O uses EXCP to a DOS interface which is then mapped to OS control blocks to be compliant with MVT EXCP processing. The code has been written for unlabelled tapes only, with specific APL\360 formatted tapes with its own internal processing to identify tape contents. QSAM is used for SYSIN/SYSOUT processing. The batch utilities should be able to run in the MVS environment but only testing will reveal any hidden problems when processing APL\360 workspaces for backup or restoration.

Recommendations

Allocate each APL\360 SWAP and LIBRARY dataset to a unique volume not used for any other purpose due to the possible risk of data corruption on the volume. The same device type must be used for all datasets.

RE-IPL MVT immediately after each APL\360 shutdown or abnormal termination to avoid the possibility of the I/O New PSW not being correctly restored. A Program Interrupt in the APL\360 control routines will not restore the I/O New PSW to the previous setting. Without the I/O New PSW being restored to pass control to the MVT I/O Supervisor then every I/O interrupt from any device will end up at the location of the APL\360 interception code whether it is there or been overwritten.

We own a great deal of thanks to Juergen for his major effort working to refurbish APL\360 in such a difficult and complex environment without the benefit of complete documentation or a complete distribution tape. It is truly work with a high degree of complexity and difficulty to understand the interaction between the various components of APL\360. We must also give thanks to Max for his work in developing 2703 Control Unit emulation. Without taking anything away from the brilliant work done by the many Hercules developers in building Hercules and its device emulation I would consider the 2703 CU to be the most difficult to emulate. The major issue is one of timing where CCWs may not be processed at Hercules speed but must respect the timing delays of the real world environment to provide a workable emulation for start-stop devices with all their quirky features.

My apologies for the long post however the APL\360 project has attracted a lot of attention and comments so I hope this post level sets everyone to the scope of this project and its ongoing issues.

Regards
Tom
Richard S Beverson
2013-01-07 11:44:51 UTC
Permalink
Hi Tom,

Thanks for the analysis.

I've already started work on my copy of APL\360 converting it to execute
as a TSO command processor (single user). This makes it easier.

I've already thrown out the EXCP stuff(as much as I like it). I use BDAM
IO with relative record access. I've written a macro to do all the
DIR & WS access with the new support module.

.*
.*Example:
.*
.* Following is a request to READ logical directory 1 into
.* storage area defined by WS3. WS3 should start PAGE
.* boundary and be large enough to hold NUM#@ x WSSIZE bytes.
.*
.* Read/Write---> DIR WS
.*
.* DISKIO CMD=READ, * DISKIO CMD=WRITE, *
.* CTRLBLK@=BLK2, * CTRLBLK@=WSBLK, *
.* TYPE=DIR, * TYPE=WS, *
.* DATA@=DIRDATA@, * DATA@=WSDATA@, *
.* DIR#@=DIR#@ LIB#@=LIB#@, *
.* REC#@=REC#@, *
.* NUM#@=NUM#@
.*

I'm starting the work on The APLUTIL module. I'm making the code 31 bit
and re-entrant. I've
altered the configuration macros to include what I need to add the
BDAM(DCBs, DECBs,CDCPARS,JFCB, etc). I removed the necessity for the
SWAP file(Since this is going to be a TSO command processor).
I chose BDAM because it allows me multiple IOs(like chained scheduling).

I have the APLINIT module almost complete.

Way back in the day I worked for an IBM fellow modifying APL to run on a
360 model 50 and a 145 .

Richard S Beverson
Post by Thomas
After the many postings regarding running the APL\360 code under MVT I
decided to look at the code in the context of moving the code to MVS
as I have had some experience in refurbishing old code.
Firstly, looking at the online component of APL\360.
The online code makes minimal use of OS/360 and where it does use
OS/360 services all of the expected integrity associated with OS/360
is circumvented by the code. The only exception being the workspace
interpreter.
All OS APL/360 code runs in Key 0 Supervisor state except when the
interpreter is dispatched with the region user key to interpret the
users workspace code which is resident in storage set to the region
user key. System/360 storage protection is used to prevent errors in
APL\360 user programs that would corrupt APL\360 code or other
resident workspaces. The storage keys and PSW key are set without the
use of any system services.
DASD I/O
APL\360 uses EXCP for all DASD processing however the dataset
integrity of EXCP processing is circumvented. The DEB file mask for
each dataset is set to zero allowing embedded cylinder SEEKs in CCW
strings. The CCW strings used by the code do have embedded SEEKs with
the CCHH DASD address calculated by the code. Therefore any error in
calculating the provided CCHH may result in I/O outside of the extents
of a SWAP or LIBRARY dataset. This will not be prevented by the MVT
I/O Supervisor and could result in corruption of other datasets on the
volume (including the VTOC).
APL\360 uses PCI, CE and Abnormal End (XE) Appendages for control of
the I/O to the SWAP and LIBRARY datasets. The provided Appendage exits
are not discreetly coded routines isolated for ease of understanding
and maintenance but are in fact dummy routines which pass control
directly into the complex APL\360 control code running disabled in Key
0 Supervisor state.
SWAP and LIBRARY dataset device characteristics are obtained from the
DEVTYPE macro. They may be allocated on 2311, 2314, 3330 or any DASD
device supported by MVT however not to any device with a track size
exceeding 14000 as that is the size of the DASD I/O area allocated in
the IM CSECT in APLSSINI. RPS Support is included in the DASD driving
code and not identified in the source as a retro fit/enhancement. An
interesting aside is that the APL\360 source code as distributed has a
date 05/11/70 whereas IBM announced 3330s in Jun 1970 so 3330s must
have been generally available inside the IBM Labs for some time before
Customer Announcement.
Terminal I/O
APL\360 does not use OS/360 for I/O to the terminal devices. Therefore
no OS/360 UCBs are required or used to drive the terminals. No OS/360
Access Method code is used. I/O to the terminals is driven directly by
SIO instructions initiating CCWs strings built and updated by AP\360.
Extensive use is made of PCI interrupts to update running channel
programs to manage the buffer pool. To implement this method of I/O,
on startup, the I/O New PSW is replaced with a PSW passing control
directly to APL\360. All I/O interrupts are received by APL\360 where
the interrupting device address is inspected and non APL\360 terminal
interrupts are passed to the MVT I/O Supervisor for processing. All
terminal I/O error processing is implemented in the APL\360 terminal
control routines. Due to the characteristics of start/stop terminal
hardware and unique characteristics of each terminal type the terminal
I/O driving code and CCW manipulation code is closely integrated with
the applications parsing and processing code.
The code is designed to run a significant number of terminals to
support a large user population in competition for computer resources
executing the APL\360 interpreter so it has been implemented using an
interrupt driven structure. Running disabled during terminal I/O would
not be possible due to the PCI driven code managing the buffer pool.
Timer Processing
Branch entry points are used to enter internal MVT Timer code for
finer granular control of timer services.
PSW Formats
The code manipulates BC Mode PSWs to dispatch various code routines.
This code would not function correctly with EC Mode PSWs
24 Bit Addressing Violation
The excellent diagnostic work by Juergen has identified the problem
with APL\360 failing when it is running above the 8MB line due to use
of hi-order flag bits in a 24 bit address field. This will make a
migration to MVS very difficult.
Batch Utility Component
The APL\360 batch utility code is compliant with standard OS/360 APIs
except that the DEB file mask is set to zero to allow cylinder SEEKs
in CCW chains. The I/O Appendages used in the online component are not
loaded for use during batch processing. Tape I/O uses EXCP to a DOS
interface which is then mapped to OS control blocks to be compliant
with MVT EXCP processing. The code has been written for unlabelled
tapes only, with specific APL\360 formatted tapes with its own
internal processing to identify tape contents. QSAM is used for
SYSIN/SYSOUT processing. The batch utilities should be able to run in
the MVS environment but only testing will reveal any hidden problems
when processing APL\360 workspaces for backup or restoration.
Recommendations
Allocate each APL\360 SWAP and LIBRARY dataset to a unique volume not
used for any other purpose due to the possible risk of data corruption
on the volume. The same device type must be used for all datasets.
RE-IPL MVT immediately after each APL\360 shutdown or abnormal
termination to avoid the possibility of the I/O New PSW not being
correctly restored. A Program Interrupt in the APL\360 control
routines will not restore the I/O New PSW to the previous setting.
Without the I/O New PSW being restored to pass control to the MVT I/O
Supervisor then every I/O interrupt from any device will end up at the
location of the APL\360 interception code whether it is there or been
overwritten.
We own a great deal of thanks to Juergen for his major effort working
to refurbish APL\360 in such a difficult and complex environment
without the benefit of complete documentation or a complete
distribution tape. It is truly work with a high degree of complexity
and difficulty to understand the interaction between the various
components of APL\360. We must also give thanks to Max for his work in
developing 2703 Control Unit emulation. Without taking anything away
from the brilliant work done by the many Hercules developers in
building Hercules and its device emulation I would consider the 2703
CU to be the most difficult to emulate. The major issue is one of
timing where CCWs may not be processed at Hercules speed but must
respect the timing delays of the real world environment to provide a
workable emulation for start-stop devices with all their quirky features.
My apologies for the long post however the APL\360 project has
attracted a lot of attention and comments so I hope this post level
sets everyone to the scope of this project and its ongoing issues.
Regards
Tom
[Non-text portions of this message have been removed]
ikj1234i
2013-01-07 13:35:06 UTC
Permalink
Post by Thomas
We own a great deal of thanks to Juergen for his major effort working to refurbish APL\360 in such a difficult and complex environment without the benefit of complete documentation or a complete distribution tape. It is truly work with a high degree of complexity and difficulty to understand the interaction between the various components of APL\360. We must also give thanks to Max for his work in developing 2703 Control Unit emulation. Without taking anything away from the brilliant work done by the many Hercules developers in building Hercules and its device emulation I would consider the 2703 CU to be the most difficult to emulate. The major issue is one of timing where CCWs may not be processed at Hercules speed but must respect the timing delays of the real world environment to provide a workable emulation for start-stop devices with all their quirky features.
Indeed - I would also like to take this opportunity to thank Juergen for his work on this project. As for the 2703 emulation, I should also think that Ivan really deserves to be mentioned prominently in this as well - I merely enhanced his pre-existing work to add async support to it.

Truly, all of us today stand on the shoulders of the prior generation of giants, the true Herculeans...

Best Regards

Max
Juergen
2013-01-07 13:36:01 UTC
Permalink
Post by Thomas
After the many postings regarding running the APL\360 code
under MVT I decided to look at the code in the context of
moving the code to MVS as I have had some experience in
refurbishing old code.
. . .
Hi Tom,

thanks for your comprehensive analysis!

I think that this confirms that an authentic implementation of APL\360 using its original environment is a reasonable first objective, while it probably won't make sense to try porting it as a whole to any other platform.

Every porting effort will have to deal with isolating the interpreter from the APL\360 supervisor and embedding it into the infrastructure provided by the target system first (like Richard does now for TSO). A project going down that road will most likely benefit from the authentic implementation for comparison purposes or regression testing.

I'm curious to see the TSO version come to life!

Cheers, Juergen
Mike Stramba
2013-01-07 20:07:52 UTC
Permalink
Post by Richard S Beverson
Hi Tom,
thanks for your comprehensive analysis!
I think that this confirms that an authentic implementation of APL\360 using
its original environment is a reasonable first objective, while it probably
won't make sense to try porting it as a whole to any other platform.
Every porting effort will have to deal with isolating the interpreter from
the APL\360 supervisor and embedding it into the infrastructure provided by
the target system first (like Richard does now for TSO).
Eh, give me a couple of days and I'll have it ported to MVS :\

... Now figuring out how your DTH function in your OPFNS ws works, is
another matter !

Even with the aid of the Dyalog help and
http://www.jsoftware.com/papers/APLDictionary1.htm I'm having trouble
making sense of that "simple" function

And I thought FORTH was hard to read / understand !

Mike
Juergen
2013-01-07 13:53:44 UTC
Permalink
Hi Max, Tom,

thanks for the flowers :-) I appreciate that!

And from my side too: I really appreciate the ongoing efforts of the Hercules developers. Without that brilliant piece of software the APL\360 resurrection project (and many others!) would have been far out of reach.

Cheers, Juergen
Post by ikj1234i
Post by Thomas
We own a great deal of thanks to Juergen for his major effort working to refurbish APL\360 in such a difficult and complex environment without the benefit of complete documentation or a complete distribution tape. It is truly work with a high degree of complexity and difficulty to understand the interaction between the various components of APL\360. We must also give thanks to Max for his work in developing 2703 Control Unit emulation. Without taking anything away from the brilliant work done by the many Hercules developers in building Hercules and its device emulation I would consider the 2703 CU to be the most difficult to emulate. The major issue is one of timing where CCWs may not be processed at Hercules speed but must respect the timing delays of the real world environment to provide a workable emulation for start-stop devices with all their quirky features.
Indeed - I would also like to take this opportunity to thank Juergen for his work on this project. As for the 2703 emulation, I should also think that Ivan really deserves to be mentioned prominently in this as well - I merely enhanced his pre-existing work to add async support to it.
Truly, all of us today stand on the shoulders of the prior generation of giants, the true Herculeans...
Best Regards
Max
Juergen
2013-01-07 20:42:19 UTC
Permalink
Post by Mike Stramba
Post by Richard S Beverson
Hi Tom,
thanks for your comprehensive analysis!
I think that this confirms that an authentic implementation
of APL\360 using its original environment is a reasonable first
objective, while it probably won't make sense to try porting it
as a whole to any other platform.
Every porting effort will have to deal with isolating the
interpreter from the APL\360 supervisor and embedding it
into the infrastructure provided by the target system first
(like Richard does now for TSO).
Eh, give me a couple of days and I'll have it ported to MVS :\
Good luck :-)
Post by Mike Stramba
... Now figuring out how your DTH function in your OPFNS ws
works, is another matter !
Even with the aid of the Dyalog help and
http://www.jsoftware.com/papers/APLDictionary1.htm I'm
having trouble making sense of that "simple" function
Hi Mike,

the function might look more complex than necessary (although still being a typical APL "one liner") due to the fact that I made it operate on scalars as well as vectors (presumably the corresponding function in the "original" OPFNS did work on scalars only) and that I have it detect the number of hex digits needed for formatting automagically. In the vector case the result is a table of equal length hex values, which means that the maximum of all elements is required to compute the number of digits... thus the on first sight perhaps unexplainable "ceilings" in the code ;-).

To understand it better test drive it for example like this:

DTH 15
DTH 16
DTH 4095
DTH 4096

and observe how it adapts the number of digits. Or use something like

DTH 130 7777 2

to see how it decides on the number of digits for the whole table. Or enter

DTH 7 I-BEAM 20

to format a full column of PERCORE addresses... and so on.

Cheers, Juergen
mark_s_waterbury
2013-01-07 22:05:15 UTC
Permalink
If I remember correctly. there never was any model of the IBM S/360 with more than 8 MB of "core" ... and since OS/360 was a real memory system, that might explain why it was coded in such a way (that it will not run "above" 8 MB).

AFAIK, it was not until CP/67 came along that you could run MVT on a (virtual) machine with more than 8 MB of "real" (virtual) memory.

(I don't even recall any models of S/370 having more than about 6 or 8 MB of real main storage, prior to about 1980.)

Anyone else recall differently?
Post by Juergen
Post by Gerhard Postpischil
LH Rx,high-order-16-bits-of-address
SLL Rx,8
For an address of X'800000', Rx should contain X'00800000', but
instead ended up containing X'FF800000' because what LH was
treating as a sign bit was being propagated to the left.
If you reduce Hercules MAINSIZE to 8, you may get other
errors but APL works, or at least I can get the same sign-on
errors without hanging MVT.
I noticed that all the table entries shown were non-zero. Unless
something else is going on, the code could be replaced by
an ICM/BNP/N (valid on 370; macro on F assembler?) and using
zero for an unassigned slot?
Hi Gerhard,
don't get me wrong: I didn't say that it isn't possible to change the code to _make_ it work (for example, the whole high order _byte_ of these addresses is completely unused), I simply stated the fact that APL\360 had not been designed to run above the 8 MB line.
The focus at this stage really is an authentic implementation, with absolutely no changes made to the original APL\360 code. I even withstood the temptation to remove that silly Shift-X, Shift-Z, backspace, newline ambiguity in the 1052-7 implementation, although this would have meant a simple two byte code change only.
And btw., concerning the 8 MB line: When they did it in the PERTERMs this way they most probably did it in many other locations too... so the change would presumably be way more complex than it seems on first sight. On the other hand, there would be no real point to fix this: Given my balloon placeholder trick APL\360 can easily be forced below the line, or else MVT could just be run with 8 MB or less core...
One thing still might be interesting to check out: If one wanted to run with x-large workspaces, for example 3 MB instead of the default 36000 byte, 4 slots would occupy 12 MB and the APL code would be forced below the line in any case. Question is, what the largest workspace size is that could feasibly be used and whether APL would be able to address memory slots above the 8 MB line? That question is indendent from the PERTERM and PERCORE locations as these always sit below the workspace slots. But then other questions come up immediately, like: How would the garbage collector behave with x-large workspaces, etc... well, I don't think that I want to dig into this for now.
Cheers, Juergen
Gerhard Postpischil
2013-01-08 00:58:18 UTC
Permalink
Post by mark_s_waterbury
If I remember correctly. there never was any model of the IBM S/360
with more than 8 MB of "core" ... and since OS/360 was a real memory
system, that might explain why it was coded in such a way (that it
will not run "above" 8 MB).
I vaguely recall IBM and some other vendors offering add-on (slow!)
storage to get over the 8MB limit. I think NASA had some machines
augmented that way.
Post by mark_s_waterbury
AFAIK, it was not until CP/67 came along that you could run MVT on a
(virtual) machine with more than 8 MB of "real" (virtual) memory.
I'm probably wrong, but I don't remember the 67 running native OS/360 at
all. But it's possible it could be done, but nobody chose to do so?
Post by mark_s_waterbury
(I don't even recall any models of S/370 having more than about 6 or
8 MB of real main storage, prior to about 1980.)
I seem to recall the 308x coming with more, but I don't recall the date.
And the 43x1 in the early eighties would support 32MB.

Gerhard Postpischil
Bradford, Vermont
mark_s_waterbury
2013-01-08 01:48:25 UTC
Permalink
IBM extended memory was called LCS for "Large Capacity Storage" and it was much slower than normal core. It was not only for "above 8MB" -- early on, I remember S/360 models with 1 MB of CORE and 2 MB of LCS. Look in the APL\360 source code and you will see that it checks to see if running in a region that is in LCS and if so, it aborts with an error message.

I worked at a large installation that routinely ran OS/360 MVT under CP/67 ... The first few releases of CP/67 created a S/360 (real mode) virtual machine. It was not until relesase 3 that you could run a 360-67 virtual machine (with DAT ON) and thus run CP-67 under CP-67 ... (like VM under VM in VM/370 ...).

Yes, by the time the 3081 was introduced, it supported larger real main storage sizes, but that was not until the 1980s.
Post by Gerhard Postpischil
Post by mark_s_waterbury
If I remember correctly. there never was any model of the IBM S/360
with more than 8 MB of "core" ... and since OS/360 was a real memory
system, that might explain why it was coded in such a way (that it
will not run "above" 8 MB).
I vaguely recall IBM and some other vendors offering add-on (slow!)
storage to get over the 8MB limit. I think NASA had some machines
augmented that way.
Post by mark_s_waterbury
AFAIK, it was not until CP/67 came along that you could run MVT on a
(virtual) machine with more than 8 MB of "real" (virtual) memory.
I'm probably wrong, but I don't remember the 67 running native OS/360 at
all. But it's possible it could be done, but nobody chose to do so?
Post by mark_s_waterbury
(I don't even recall any models of S/370 having more than about 6 or
8 MB of real main storage, prior to about 1980.)
I seem to recall the 308x coming with more, but I don't recall the date.
And the 43x1 in the early eighties would support 32MB.
Gerhard Postpischil
Bradford, Vermont
Dave Wade
2013-01-08 07:34:29 UTC
Permalink
Newcastle upon Tyne sometimes ran both MFT and later MVT instead of MTS. I
used it as the project scheduling tool hadn't been ported to MTS.
If I remember correctly. there never was any model of...
I vaguely recall IBM and some other vendors offering add-on (slow!)
storage to get over the 8MB limit. I think NASA had some machines
augmented that way.
AFAIK, it was not until CP/67 came along that you could run MVT on a
(virtual) machine with mor...
I'm probably wrong, but I don't remember the 67 running native OS/360 at
all. But it's possible it could be done, but nobody chose to do so?
(I don't even recall any models of S/370 having more than about 6 or
8 MB of real main storage,...
I seem to recall the 308x coming with more, but I don't recall the date.
And the 43x1 in the early eighties would support 32MB.

Gerhard Postpischil
Bradford, Vermont



------------------------------------

</body>

<!--~-|**|PrettyHtmlStart|**|-~-->
<head>
<style type="text/css">
<!--
#ygrp-mkp {
border: 1px solid #d8d8d8;
font-family: Arial;
margin: 10px 0;
padding: 0 10px;
}

#ygrp-mkp hr {
border: 1px solid #d8d8d8;
}

#ygrp-mkp #hd {
color: #628c2a;
font-size: 85%;
font-weight: 700;
line-height: 122%;
margin: 10px 0;
}

#ygrp-mkp #ads {
margin-bottom: 10px;
}

#ygrp-mkp .ad {
padding: 0 0;
}

#ygrp-mkp .ad p {
margin: 0;
}

#ygrp-mkp .ad a {
color: #0000ff;
text-decoration: none;
}
#ygrp-sponsor #ygrp-lc {
font-family: Arial;
}

#ygrp-sponsor #ygrp-lc #hd {
margin: 10px 0px;
font-weight: 700;
font-size: 78%;
line-height: 122%;
}

#ygrp-sponsor #ygrp-lc .ad {
margin-bottom: 10px;
padding: 0 0;
}

#actions {
font-family: Verdana;
font-size: 11px;
padding: 10px 0;
}

#activity {
background-color: #e0ecee;
float: left;
font-family: Verdana;
font-size: 10px;
padding: 10px;
}

#activity span {
font-weight: 700;
}

#activity span:first-child {
text-transform: uppercase;
}

#activity span a {
color: #5085b6;
text-decoration: none;
}

#activity span span {
color: #ff7900;
}

#activity span .underline {
text-decoration: underline;
}

.attach {
clear: both;
display: table;
font-family: Arial;
font-size: 12px;
padding: 10px 0;
width: 400px;
}

.attach div a {
text-decoration: none;
}

.attach img {
border: none;
padding-right: 5px;
}

.attach label {
display: block;
margin-bottom: 5px;
}

.attach label a {
text-decoration: none;
}

blockquote {
margin: 0 0 0 4px;
}

.bold {
font-family: Arial;
font-size: 13px;
font-weight: 700;
}

.bold a {
text-decoration: none;
}

dd.last p a {
font-family: Verdana;
font-weight: 700;
}

dd.last p span {
margin-right: 10px;
font-family: Verdana;
font-weight: 700;
}

dd.last p span.yshortcuts {
margin-right: 0;
}

div.attach-table div div a {
text-decoration: none;
}

div.attach-table {
width: 400px;
}

div.file-title a, div.file-title a:active, div.file-title a:hover, div.file-title a:visited {
text-decoration: none;
}

div.photo-title a, div.photo-title a:active, div.photo-title a:hover, div.photo-title a:visited {
text-decoration: none;
}

div#ygrp-mlmsg #ygrp-msg p a span.yshortcuts {
font-family: Verdana;
font-size: 10px;
font-weight: normal;
}

.green {
color: #628c2a;
}

.MsoNormal {
margin: 0 0 0 0;
}

o {
font-size: 0;
}

#photos div {
float: left;
width: 72px;
}

#photos div div {
border: 1px solid #666666;
height: 62px;
overflow: hidden;
width: 62px;
}

#photos div label {
color: #666666;
font-size: 10px;
overflow: hidden;
text-align: center;
white-space: nowrap;
width: 64px;
}

#reco-category {
font-size: 77%;
}

#reco-desc {
font-size: 77%;
}

.replbq {
margin: 4px;
}

#ygrp-actbar div a:first-child {
/* border-right: 0px solid #000;*/
margin-right: 2px;
padding-right: 5px;
}

#ygrp-mlmsg {
font-size: 13px;
font-family: Arial, helvetica,clean, sans-serif;
*font-size: small;
*font: x-small;
}

#ygrp-mlmsg table {
font-size: inherit;
font: 100%;
}

#ygrp-mlmsg select, input, textarea {
font: 99% Arial, Helvetica, clean, sans-serif;
}

#ygrp-mlmsg pre, code {
font:115% monospace;
*font-size:100%;
}

#ygrp-mlmsg * {
line-height: 1.22em;
}

#ygrp-mlmsg #logo {
padding-bottom: 10px;
}


#ygrp-msg p a {
font-family: Verdana;
}

#ygrp-msg p#attach-count span {
color: #1E66AE;
font-weight: 700;
}

#ygrp-reco #reco-head {
color: #ff7900;
font-weight: 700;
}

#ygrp-reco {
margin-bottom: 20px;
padding: 0px;
}

#ygrp-sponsor #ov li a {
font-size: 130%;
text-decoration: none;
}

#ygrp-sponsor #ov li {
font-size: 77%;
list-style-type: square;
padding: 6px 0;
}

#ygrp-sponsor #ov ul {
margin: 0;
padding: 0 0 0 8px;
}

#ygrp-text {
font-family: Georgia;
}

#ygrp-text p {
margin: 0 0 1em 0;
}

#ygrp-text tt {
font-size: 120%;
}

#ygrp-vital ul li:last-child {
border-right: none !important;
}
-->
</style>
</head>

<!--~-|**|PrettyHtmlEnd|**|-~-->
</html>
<!-- end group email -->
Tony Harminc
2013-01-08 05:07:49 UTC
Permalink
Post by mark_s_waterbury
(I don't even recall any models of S/370 having more than about 6 or 8 MB of real main storage, prior to about 1980.)
Anyone else recall differently?
In Feb 1977 - just coming up on the 35th anniversary - there was a
major fire in the building housing the Computer Centre at the
University of Toronto. We moved operations to an IBM facility for the
week it took to get things cleaned up, and we ran our MVT on a 370/168
with 16 MB of storage. I remember an argument about whether an S0C5
was possible on such a machine, but of course since we were running
under VM, it was not a well formed question.

So not that it was common in the real world, but yes - there existed
IBM S/370 hardware with 16 MB in early 1977.

Tony H.
mark_s_waterbury
2013-01-08 13:59:22 UTC
Permalink
Hi, Tony:

I was mostly speaking to the maximum real main storage ("core") that could be put on any model of S/360 (e.g. when APL\360 was written).

I recall that the S/370 line supported up to the full 16 MB for real main storage, e.g. 24-bits of address. Eventually, (early '80s?) so-called "extended" addressing was introduced supporting 26 bits for the real address in hardware.

I also seem to recall that OS/360 MVT, as distributed, would support only up to 8 MB of memory, without some "local mods". What I was saying was that it was not possible to have more than 8 MB of real "core" memory on a S/360, when APL\360 was developed, and that might explain why it was coded the way it was ... (and so APL\360 will not run above 8 MB, without modifications.)

Mark
Post by Tony Harminc
Post by mark_s_waterbury
(I don't even recall any models of S/370 having more than about 6 or 8 MB of real main storage, prior to about 1980.)
Anyone else recall differently?
In Feb 1977 - just coming up on the 35th anniversary - there was a
major fire in the building housing the Computer Centre at the
University of Toronto. We moved operations to an IBM facility for the
week it took to get things cleaned up, and we ran our MVT on a 370/168
with 16 MB of storage. I remember an argument about whether an S0C5
was possible on such a machine, but of course since we were running
under VM, it was not a well formed question.
So not that it was common in the real world, but yes - there existed
IBM S/370 hardware with 16 MB in early 1977.
Tony H.
John P. Hartmann
2013-01-08 15:51:36 UTC
Permalink
Could have up to 4 boxes of 2365 core storage (256K each) attached to any
/65 or /75 for a total of one enormous meg. Guess 65MP could address eight
of those boxes; a 67 certainly could. The mode /85 used a different mode
core with double the capacity.
Post by mark_s_waterbury
**
I was mostly speaking to the maximum real main storage ("core") that could
be put on any model of S/360 (e.g. when APL\360 was written).
I recall that the S/370 line supported up to the full 16 MB for real main
storage, e.g. 24-bits of address. Eventually, (early '80s?) so-called
"extended" addressing was introduced supporting 26 bits for the real
address in hardware.
I also seem to recall that OS/360 MVT, as distributed, would support only
up to 8 MB of memory, without some "local mods". What I was saying was that
it was not possible to have more than 8 MB of real "core" memory on a
S/360, when APL\360 was developed, and that might explain why it was coded
the way it was ... (and so APL\360 will not run above 8 MB, without
modifications.)
Mark
[Non-text portions of this message have been removed]
Carter Browne
2013-01-08 17:04:35 UTC
Permalink
Around 1969-1970 IBM had a product called LCS (large core storage) which, if I
remember correctly, came in either 4MB or 8MB units of 8usec core memory. At
the place I was working we had a 360/50 running MFT-II with 4MB (it might have
been 8MB, it was a while ago). One major limitation was it could only support
access from 1 high speed channel operation at a time, more than 1 would result
in data channel overruns. It was clearly a hint, even at that time, that a
24bit address was going to be a limitation.

Carter Browne
Post by John P. Hartmann
Could have up to 4 boxes of 2365 core storage (256K each) attached to any
/65 or /75 for a total of one enormous meg. Guess 65MP could address eight
of those boxes; a 67 certainly could. The mode /85 used a different mode
core with double the capacity.
Post by mark_s_waterbury
**
I was mostly speaking to the maximum real main storage ("core") that could
be put on any model of S/360 (e.g. when APL\360 was written).
I recall that the S/370 line supported up to the full 16 MB for real main
storage, e.g. 24-bits of address. Eventually, (early '80s?) so-called
"extended" addressing was introduced supporting 26 bits for the real
address in hardware.
I also seem to recall that OS/360 MVT, as distributed, would support only
up to 8 MB of memory, without some "local mods". What I was saying was that
it was not possible to have more than 8 MB of real "core" memory on a
S/360, when APL\360 was developed, and that might explain why it was coded
the way it was ... (and so APL\360 will not run above 8 MB, without
modifications.)
Mark
[Non-text portions of this message have been removed]
[Non-text portions of this message have been removed]
Dave
2013-01-08 21:52:51 UTC
Permalink
Post by John P. Hartmann
Could have up to 4 boxes of 2365 core storage (256K each) attached to any
/65 or /75 for a total of one enormous meg. Guess 65MP could address eight
of those boxes; a 67 certainly could. The mode /85 used a different mode
core with double the capacity.
Post by mark_s_waterbury
**
I was mostly speaking to the maximum real main storage ("core") that could
be put on any model of S/360 (e.g. when APL\360 was written).
I recall that the S/370 line supported up to the full 16 MB for real main
storage, e.g. 24-bits of address. Eventually, (early '80s?) so-called
"extended" addressing was introduced supporting 26 bits for the real
address in hardware.
I also seem to recall that OS/360 MVT, as distributed, would support only
up to 8 MB of memory, without some "local mods". What I was saying was that
it was not possible to have more than 8 MB of real "core" memory on a
S/360, when APL\360 was developed, and that might explain why it was coded
the way it was ... (and so APL\360 will not run above 8 MB, without
modifications.)
Some pictures of a 360/67 here:-

http://history.cs.ncl.ac.uk/anniversaries/40th/images/ibm360_672/index.html
Post by John P. Hartmann
Post by mark_s_waterbury
Mark
[Non-text portions of this message have been removed]
------------------------------------
Kevin Leonard
2013-01-09 22:21:57 UTC
Permalink
Juergen:

I'm home from the holidays, and getting caught up.
Post by Juergen
So, I considered the region location dependency as "works as
designed": It is a permanent restriction that the APL\360 region
has to be located below the 8-MB line.
That's pretty much what I expected. Probably the least complicated
thing we can do is limit real storage in the Hercules configuration
file by specifying "MAINSIZE 8". Oh, well.

Hope to get a functioning APL environment built shortly. Thanks for
all the great work you've done on it.
--
Kevin
Juergen
2013-01-13 13:29:02 UTC
Permalink
Post by Kevin Leonard
I'm home from the holidays, and getting caught up.
Hi Kevin,

good to see you back!

I'm back too, not from holidays though, but from an emergency surgery due to cutting my left thumb's ulnopalmar ateria and nervs -- while drinking tea, loosing grip of the mug, catching it too hard in free fall causing it to dissipate and almost cutting my thumb off. Never thought that drinking tea can be that dangerous :-(

Well, my left hand is in a plaster bandage and I'm severly handicapped using the keyboard since a few days now... but it's getting better :-)
Post by Kevin Leonard
Post by Juergen
So, I considered the region location dependency as "works as
designed": It is a permanent restriction that the APL\360 region
has to be located below the 8-MB line.
That's pretty much what I expected. Probably the least complicated
thing we can do is limit real storage in the Hercules configuration
file by specifying "MAINSIZE 8". Oh, well.
Yes, that's for sure an easy way out. On the other hand the balloon doesn't work too bad. So that dependency isn't critical, it was just important to identify it to be sure that it isn't an implementation issue.
Post by Kevin Leonard
Hope to get a functioning APL environment built shortly. Thanks for
all the great work you've done on it.
If you haven't started yet: Just wait until this evening, I'll be coming up with a new OPFNS version and my other sample workspaces on a utility full dump tape, which can be used in the CREATE operation during APL installation instead of the empty one contained in the distribution. So you don't need to install it manually...

Cheers, Juergen
Mike Stramba
2013-01-13 18:44:21 UTC
Permalink
Post by Juergen
I'm back too, not from holidays though, but from an emergency surgery due to
cutting my left thumb's ulnopalmar ateria and nervs -- while drinking tea,
loosing grip of the mug, catching it too hard in free fall causing it to
dissipate and almost cutting my thumb off. Never thought that drinking tea
can be that dangerous :-(
Well, my left hand is in a plaster bandage and I'm severly handicapped using
the keyboard since a few days now... but it's getting better :-)
Holy crap !

By "dissipate", I take it, you mean it broke / shattered, when it
hit your hand ?

Should have let it hit the floor.

Ya .. then it would probably have shattered and blinded you :\

Mike
Juergen
2013-01-13 13:58:06 UTC
Permalink
Post by Juergen
Post by Gerhard Postpischil
Post by Juergen
All documentation that can be found mentions the importance
of a correct priority setting. From my point of view a bit
mystic on a system on which no one else competes for resources,
but in general those developers new what they did. Bottomline
for me is, to not ignore the sparse recommendations relevant
for MVT found scattered around source and documentation
(remember: most sysprog type doc is for the DOS version...).
Perhaps I'm missing something. If priority is the only issue,
why can't it be a start job? I use EXEC ... DPRTY=(15,13)
on one of my jobs, and only JES and GTF are higher (at 15,15).
(15,13) appears to be the most frequent value for STCs, with
only TCAM being lower. So you could use (15,14).
Hi Gerhard,
you're right, of course. Sometimes it doesn't harm to
review conclusions made in an early stage later on...
. . .
And, as expected, it sails smoothly ;-)
Of course I still have to verify stability on a longer run.
But I don't expect surprises: Given the above thoughts it should
work equally well or better now than when running under HASP, as
priority handling should now work correctly.
I now did a multi day run and some heavy stress testing. As expected it is rock solid. So I changed the implementation to run APL and the balloon as an STC now and changed the balloon at the same time enhancing it to honor the STOP (P) command instead of the ugly cancel. This will become available in the next version of the distribution.
Post by Juergen
I'm particularily curious whether the consistently missing
midnight date advance action (most probably a timing/priority
issue) will now get catched...
Well, that wish didn't come true :-(

So I took a closer look at the source (should have done this earlier!) only to find that it is plain and simple: A bug. That code cannot work and can never have worked: The current date is set at startup time only and then never updated again ;-)

The code in fact looks as if some emergency editing has taken place to prevent APL from getting irritated if the MVT operator chose to set (reset) the clock and date while APL is running. Well, they did it perfectly, APL is completely ignorant now.

I assume that this bug was introduced shortly before V1M1 (our source) was released and it didn't run through full testing. Most probably it got detected and fixed shortly after release... I at least cannot imagine that people accepted a software that doesn't increment the date but instead produces days being longer than 24 hours.

As far as I can see up to now a fix wouldn't be complicated to create (but it's more than just a silly two liner...). For now, still being in "authentic mode" (and too lazy...), I refrain from doing it. But, as an intermediate solution, I implemented a function to manually set the date in the upcoming new version of the OPFNS workspace.

Cheers, Juergen
j***@public.gmane.org
2013-01-13 14:43:58 UTC
Permalink
----- Original Message -----
From: "Juergen" <winkelmann-***@public.gmane.org>
To: hercules-390-***@public.gmane.org
Sent: Sunday, January 13, 2013 7:58:06 AM
Subject: [hercules-390] Re: Running APL\360 on OS/360-MVT 21.8F
Post by Juergen
Post by Gerhard Postpischil
Post by Juergen
All documentation that can be found mentions the importance
of a correct priority setting. From my point of view a bit
mystic on a system on which no one else competes for resources,
but in general those developers new what they did. Bottomline
for me is, to not ignore the sparse recommendations relevant
for MVT found scattered around source and documentation
(remember: most sysprog type doc is for the DOS version...).
Perhaps I'm missing something. If priority is the only issue,
why can't  it be a start job?  I use EXEC ... DPRTY=(15,13)
on one of my jobs, and only JES and GTF are higher (at 15,15).
(15,13) appears to be the most frequent value for STCs, with
only TCAM being lower. So you could use (15,14).
Hi Gerhard,
you're right, of course. Sometimes it doesn't harm to
review conclusions made in an early stage later on...
. . .
And, as expected, it sails smoothly ;-)
Of course I still have to verify stability on a longer run.
But I don't expect surprises: Given the above thoughts it should
work equally well or better now than when running under HASP, as
priority handling should now work correctly.
I now did a multi day run and some heavy stress testing. As expected it is rock solid. So I changed the implementation to run APL and the balloon as an STC now and changed the balloon at the same time enhancing it to honor the STOP (P) command instead of the ugly cancel. This will become available in the next version of the distribution.
Post by Juergen
I'm particularily curious whether the consistently missing
midnight date advance action (most probably a timing/priority
issue) will now get catched...
Well, that wish didn't come true :-(

So I took a closer look at the source (should have done this earlier!) only to find that it is plain and simple: A bug. That code cannot work and can never have worked: The current date is set at startup time only and then never updated again ;-)

The code in fact looks as if some emergency editing has taken place to prevent APL from getting irritated if the MVT operator chose to set (reset) the clock and date while APL is running. Well, they did it perfectly, APL is completely ignorant now.

I assume that this bug was introduced shortly before V1M1 (our source) was released and it didn't run through full testing. Most probably it got detected and fixed shortly after release... I at least cannot imagine that people accepted a software that doesn't increment the date but instead produces days being longer than 24 hours.

As far as I can see up to now a fix wouldn't be complicated to create (but it's more than just a silly two liner...). For now, still being in "authentic mode" (and too lazy...), I refrain from doing it. But, as an intermediate solution, I implemented a function to manually set the date in the upcoming new version of the OPFNS workspace.

Cheers, Juergen




------------------------------------

</body>

<!--~-|**|PrettyHtmlStart|**|-~-->
<head>
<style type="text/css">
<!--
#ygrp-mkp {
border: 1px solid #d8d8d8;
font-family: Arial;
margin: 10px 0;
padding: 0 10px;
}

#ygrp-mkp hr {
border: 1px solid #d8d8d8;
}

#ygrp-mkp #hd {
color: #628c2a;
font-size: 85%;
font-weight: 700;
line-height: 122%;
margin: 10px 0;
}

#ygrp-mkp #ads {
margin-bottom: 10px;
}

#ygrp-mkp .ad {
padding: 0 0;
}

#ygrp-mkp .ad p {
margin: 0;
}

#ygrp-mkp .ad a {
color: #0000ff;
text-decoration: none;
}
#ygrp-sponsor #ygrp-lc {
font-family: Arial;
}

#ygrp-sponsor #ygrp-lc #hd {
margin: 10px 0px;
font-weight: 700;
font-size: 78%;
line-height: 122%;
}

#ygrp-sponsor #ygrp-lc .ad {
margin-bottom: 10px;
padding: 0 0;
}

#actions {
font-family: Verdana;
font-size: 11px;
padding: 10px 0;
}

#activity {
background-color: #e0ecee;
float: left;
font-family: Verdana;
font-size: 10px;
padding: 10px;
}

#activity span {
font-weight: 700;
}

#activity span:first-child {
text-transform: uppercase;
}

#activity span a {
color: #5085b6;
text-decoration: none;
}

#activity span span {
color: #ff7900;
}

#activity span .underline {
text-decoration: underline;
}

.attach {
clear: both;
display: table;
font-family: Arial;
font-size: 12px;
padding: 10px 0;
width: 400px;
}

.attach div a {
text-decoration: none;
}

.attach img {
border: none;
padding-right: 5px;
}

.attach label {
display: block;
margin-bottom: 5px;
}

.attach label a {
text-decoration: none;
}

blockquote {
margin: 0 0 0 4px;
}

.bold {
font-family: Arial;
font-size: 13px;
font-weight: 700;
}

.bold a {
text-decoration: none;
}

dd.last p a {
font-family: Verdana;
font-weight: 700;
}

dd.last p span {
margin-right: 10px;
font-family: Verdana;
font-weight: 700;
}

dd.last p span.yshortcuts {
margin-right: 0;
}

div.attach-table div div a {
text-decoration: none;
}

div.attach-table {
width: 400px;
}

div.file-title a, div.file-title a:active, div.file-title a:hover, div.file-title a:visited {
text-decoration: none;
}

div.photo-title a, div.photo-title a:active, div.photo-title a:hover, div.photo-title a:visited {
text-decoration: none;
}

div#ygrp-mlmsg #ygrp-msg p a span.yshortcuts {
font-family: Verdana;
font-size: 10px;
font-weight: normal;
}

.green {
color: #628c2a;
}

.MsoNormal {
margin: 0 0 0 0;
}

o {
font-size: 0;
}

#photos div {
float: left;
width: 72px;
}

#photos div div {
border: 1px solid #666666;
height: 62px;
overflow: hidden;
width: 62px;
}

#photos div label {
color: #666666;
font-size: 10px;
overflow: hidden;
text-align: center;
white-space: nowrap;
width: 64px;
}

#reco-category {
font-size: 77%;
}

#reco-desc {
font-size: 77%;
}

.replbq {
margin: 4px;
}

#ygrp-actbar div a:first-child {
/* border-right: 0px solid #000;*/
margin-right: 2px;
padding-right: 5px;
}

#ygrp-mlmsg {
font-size: 13px;
font-family: Arial, helvetica,clean, sans-serif;
*font-size: small;
*font: x-small;
}

#ygrp-mlmsg table {
font-size: inherit;
font: 100%;
}

#ygrp-mlmsg select, input, textarea {
font: 99% Arial, Helvetica, clean, sans-serif;
}

#ygrp-mlmsg pre, code {
font:115% monospace;
*font-size:100%;
}

#ygrp-mlmsg * {
line-height: 1.22em;
}

#ygrp-mlmsg #logo {
padding-bottom: 10px;
}


#ygrp-msg p a {
font-family: Verdana;
}

#ygrp-msg p#attach-count span {
color: #1E66AE;
font-weight: 700;
}

#ygrp-reco #reco-head {
color: #ff7900;
font-weight: 700;
}

#ygrp-reco {
margin-bottom: 20px;
padding: 0px;
}

#ygrp-sponsor #ov li a {
font-size: 130%;
text-decoration: none;
}

#ygrp-sponsor #ov li {
font-size: 77%;
list-style-type: square;
padding: 6px 0;
}

#ygrp-sponsor #ov ul {
margin: 0;
padding: 0 0 0 8px;
}

#ygrp-text {
font-family: Georgia;
}

#ygrp-text p {
margin: 0 0 1em 0;
}

#ygrp-text tt {
font-size: 120%;
}

#ygrp-vital ul li:last-child {
border-right: none !important;
}
-->
</style>
</head>

<!--~-|**|PrettyHtmlEnd|**|-~-->
</html>
<!-- end group email -->
Gregg Levine
2013-01-13 18:18:17 UTC
Permalink
<Deleted!>
Hello!
Please do not do that. Please look at the information stated there:
It will remove you.

-----
Gregg C Levine gregg.drwho8-***@public.gmane.org
"This signature fought the Time Wars, time and again."
Gerhard Postpischil
2013-01-13 20:24:35 UTC
Permalink
Post by Juergen
So I took a closer look at the source (should have done this
earlier!) only to find that it is plain and simple: A bug. That code
cannot work and can never have worked: The current date is set at
startup time only and then never updated again ;-)
I don't remember that at all, and we ran MVT from release 14 through
21.7 or 21.8. I do remember a strong admonition never to use CVTDATE, as
the midnight timer interrupt might not have updated it yet, whereas an
SVC 11 (DATE) call forced synchronization.

Gerhard Postpischil
Bradford, Vermont

P.S. Hope your thumb gets better soon. As a teen I sliced my thumb while
opening a "tin" can, and fifty years later there is only a hint of a scar.
Juergen
2013-01-13 21:21:59 UTC
Permalink
Post by Gerhard Postpischil
Post by Juergen
So I took a closer look at the source (should have done
this earlier!) only to find that it is plain and simple: A bug.
That code cannot work and can never have worked: The current
date is set at startup time only and then never updated again ;-)
I don't remember that at all, and we ran MVT from release 14
through 21.7 or 21.8. I do remember a strong admonition never
to use CVTDATE, as the midnight timer interrupt might not
have updated it yet, whereas an SVC 11 (DATE) call forced
synchronization.
Hi Gerhard,

I didn't express myself clear enough: It's an APL\360 bug, not an MVT bug. The MVT TIME service works flawlessly if only APL would call it at midnight to set the new date: APL detects midnight, bumps up the time counter by 24 hours and simply doesn't call for the new date ;-)
Post by Gerhard Postpischil
P.S. Hope your thumb gets better soon. As a teen I sliced my
thumb while opening a "tin" can, and fifty years later there
is only a hint of a scar.
Thanks! Momentarily that nerve that they've somehow glued together tells me lots of weird things but not what my thumb really feels like... ;-)

Cheers, Juergen
somitcw
2013-01-13 18:28:00 UTC
Permalink
Post by Juergen
don't get me wrong: I didn't say that it isn't possible to
change the code to _make_ it work (for example, ...
It does bring to mind an MVT change we picked up at SHARE
in the mid-seventies. It provides storage "fencing" allowing
the installation to create virtual partitions, and directing
jobs to those partitions ...
IMO, OS/MFT, where jobs are assigned to fixed, predefined >partitions, looks like a better APL\360 host to me. MFT is
easier to set up and runs leaner. MFT was "the poor men's MVT"
because it needed anywhere from 128...256K less *core* than
MVT would need for the same corporate workload.
Except for anything using an IKJ macro/feature (TSO ATTACH
/ DETACH) and a few special MVT-only options (like
CHECKPOINT/RESTART), if it ran in an MVT region it also ran
mighty fine in an MFT partition.
Andreas Geissbuehler
MFT-II did not have native TSO.
MFT-II did have ATTACH/DETACH but perhaps not all of the options?
I don't believe that the hierarchical storage options worked?
PCP only simulated ATTACH/DETACH by looking like it did a
LINK/RETURN but MFT-II worked normal.
MFT-II had Checkpoint/Restart which we used way too much.
Gerhard Postpischil
2013-01-13 20:15:46 UTC
Permalink
Post by somitcw
MFT-II did not have native TSO.
MFT-II did have ATTACH/DETACH but perhaps not all of the options?
I don't believe that the hierarchical storage options worked?
PCP only simulated ATTACH/DETACH by looking like it did a
LINK/RETURN but MFT-II worked normal.
MFT-II had Checkpoint/Restart which we used way too much.
Multi-tasking was a fairly late addition for MFT. ADR had a CIA contract
to convert a batch document retrieval system to an on-line multi-user
system on the then nearly new 2260s. I had to write my own
mini-dispatcher, enqueue mechanism, could not use XCTL, etc. At least I
never had to run under MFT-I.

Gerhard Postpischil
Bradford, Vermont
Juergen
2013-01-13 19:03:15 UTC
Permalink
Post by Mike Stramba
Post by Juergen
I'm back too, not from holidays though, but from an
emergency surgery due to cutting my left thumb's
ulnopalmar ateria and nervs -- while drinking tea,
loosing grip of the mug, catching it too hard in free
fall causing it to dissipate and almost cutting my
thumb off. Never thought that drinking tea can be
that dangerous :-(
Well, my left hand is in a plaster bandage and I'm
severly handicapped using the keyboard since a few
days now... but it's getting better :-)
Holy crap !
By "dissipate", I take it, you mean it broke / shattered,
when it hit your hand ?
Exactly! I got hold of it, already thought how lucky I was, when I realized that it had collapsed in my hand and the blood spurted out of my thumb in the rythm of my heartbeat from the cut arterial. Until I managed to stop it with a pack of paper towels my desk and my face were covered with blood, I must have looked like after an assassination attempt, at least I read this from the faces of my colleages. Well, guess what was written on the mug? IBM! Our IBM sales gave it to me just a month or so ago, as until then I used to use an EMC mug, which he hated :-(

Cheers, Juergen
Tony Harminc
2013-01-14 03:38:11 UTC
Permalink
Post by Juergen
Exactly! I got hold of it, already thought how lucky I was, when I realized that it had collapsed in my hand and the blood spurted out of my thumb in the rythm of my heartbeat from the cut arterial. Until I managed to stop it with a pack of paper towels my desk and my face were covered with blood, I must have looked like after an assassination attempt, at least I read this from the faces of my colleages.
Yow! I hope all goes well. Damaged nerves can be no fun, as I
discovered when I broke my wrist in 1980.
Post by Juergen
Well, guess what was written on the mug? IBM! Our IBM sales gave it to me just a month or so ago, as until then I used to use an EMC mug, which he hated :-(
Heh - vendor mug wars. Also works with those fancy leather
binders/portfolios. You always use the one from the other guys when
each vendor is visiting, and then they up the stakes with increasingly
better swag.

Tony H.
Tony Harminc
2013-02-07 21:36:59 UTC
Permalink
I was browsing the old VMSHARE database looking for something else,
and came across this piece of APL arcana from 1988:

=========================
Append on 11/22/88 at 18:01 by Bill Temps, First Chicago Corporation:

APL trivia: what do you get from (floor)(slash)(iota)0? (That's
the numeric digit zero). Hint: I don't think there's any way to
derive this from the definitions of the individual operators. Bonus
question: what do you get if you replace (floor) by (ceiling)?
(Also known as minimum and maximum, and downstile and upstile.)

*** APPENDED 11/22/88 18:01:13 BY FNC/WHT3 ***

Append on 11/23/88 at 20:07 by Barry Leiba:

They give you the largest and smallest real numbers that your APL
implementation can work with.

*** APPENDED 11/23/88 20:07:15 BY .BL ***

Append on 11/24/88 at 14:17 by Bill Temps, First Chicago Corporation:

Right, Barry. I only just recently found out about this.

*** APPENDED 11/24/88 14:17:15 BY FNC/WHT3 ***

Append on 11/25/88 at 20:44 by Alan Ackerman, Bank of America:

(floor)(slash)(iota)0 is asking for the minimum of an empty set, which
is (matchematically-speaking) undefined. (The minimum of a set has to be
a member of the set, and an empty set has no members.) The generalization
of minimum to more general sets is "greatest lower bound" (or glb).
The glb of the empty set is +infinity, so APLs choice of the largest positive
number is certainly reasonable (it is the greatest lower bound that APL
can express, anyway).

*** APPENDED 11/25/88 20:44:24 BY BAM/ACKERMAN ***
=========================

Tony H.
Mark Morgan Lloyd
2013-02-08 08:59:59 UTC
Permalink
Post by Tony Harminc
I was browsing the old VMSHARE database looking for something else,
=========================
APL trivia: what do you get from (floor)(slash)(iota)0? (That's
the numeric digit zero). Hint: I don't think there's any way to
derive this from the definitions of the individual operators. Bonus
question: what do you get if you replace (floor) by (ceiling)?
(Also known as minimum and maximum, and downstile and upstile.)
*** APPENDED 11/22/88 18:01:13 BY FNC/WHT3 ***
They give you the largest and smallest real numbers that your APL
implementation can work with.
*** APPENDED 11/23/88 20:07:15 BY .BL ***
Right, Barry. I only just recently found out about this.
*** APPENDED 11/24/88 14:17:15 BY FNC/WHT3 ***
(floor)(slash)(iota)0 is asking for the minimum of an empty set, which
is (matchematically-speaking) undefined. (The minimum of a set has to be
a member of the set, and an empty set has no members.) The generalization
of minimum to more general sets is "greatest lower bound" (or glb).
The glb of the empty set is +infinity, so APLs choice of the largest positive
number is certainly reasonable (it is the greatest lower bound that APL
can express, anyway).
Interesting. Is this the only case where an empty (zero-length) array is
significant? I'm obviously going to have to check how my own APL
implementation evaluates this.
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
Bert Lindeman
2013-01-14 09:03:54 UTC
Permalink
Yuck...

Wish you a speedy and complete recovery, Juergen.

Bert
Post by Juergen
Post by Mike Stramba
Post by Juergen
I'm back too, not from holidays though, but from an
emergency surgery due to cutting my left thumb's
ulnopalmar ateria and nervs -- while drinking tea,
loosing grip of the mug, catching it too hard in free
fall causing it to dissipate and almost cutting my
thumb off. Never thought that drinking tea can be
that dangerous :-(
Well, my left hand is in a plaster bandage and I'm
severly handicapped using the keyboard since a few
days now... but it's getting better :-)
Holy crap !
By "dissipate", I take it, you mean it broke / shattered,
when it hit your hand ?
Exactly! I got hold of it, already thought how lucky I was, when I realized that it had collapsed in my hand and the blood spurted out of my thumb in the rythm of my heartbeat from the cut arterial. Until I managed to stop it with a pack of paper towels my desk and my face were covered with blood, I must have looked like after an assassination attempt, at least I read this from the faces of my colleages. Well, guess what was written on the mug? IBM! Our IBM sales gave it to me just a month or so ago, as until then I used to use an EMC mug, which he hated :-(
Cheers, Juergen
------------------------------------
http://groups.yahoo.com/group/hercules-390
http://www.hercules-390.org
Yahoo! Groups Links
-----
Geen virus gevonden in dit bericht.
Gecontroleerd door AVG - www.avg.com
Versie: 2013.0.2890 / Virusdatabase: 2638/6026 - datum van uitgifte: 01/11/13
Kevin Leonard
2013-01-13 21:12:20 UTC
Permalink
Post by Juergen
I'm back too, not from holidays though, but from an emergency
surgery due to cutting my left thumb's ulnopalmar ateria and nervs
-- while drinking tea, loosing grip of the mug, catching it too
hard in free fall causing it to dissipate and almost cutting my
thumb off. Never thought that drinking tea can be that dangerous
:-(
Good heavens. Glad you're OK. That's really scary, certainly not
the behavior you would expect from a well-behaved cup of tea. It's
a good thing this happened somewhere other than the United States so
you could get medical treatment.

I got the 1.00 APL distribution built with no problems, and it works
great. Not only have you done a whole lot of work on the product, but
your documentation is awesome. Thank you so much. It's taking me
back to high school, where I learned to program using, among other
things, the DOS version of this APL product on a 2741 connected at
a whopping 134.5 bits per second to a System/360 Model 40.
Post by Juergen
guess what was written on the mug? IBM! Our IBM sales gave it to me
just a month or so ago, as until then I used to use an EMC mug,
which he hated
You might consider returning the pieces to IBM and mentioning how
crummy the IBM mug turned out to be compared with its competition.
Maybe there's a moral here.
--
Kevin
Juergen
2013-01-13 21:27:23 UTC
Permalink
Post by Kevin Leonard
You might consider returning the pieces to IBM and mentioning how
crummy the IBM mug turned out to be compared with its competition.
Maybe there's a moral here.
Hi Kevin,

good idea, I'm going to have lunch with him tomorrow... ;-)

Cheers, Juergen
BruceTSmith
2013-01-13 22:24:39 UTC
Permalink
I'ld file a lawsuit against IBM. And when they start talking settlement, demand a "free" life-time license to run z/OS under Hercules... :) :)

B..
Post by Juergen
Post by Kevin Leonard
You might consider returning the pieces to IBM and mentioning how
crummy the IBM mug turned out to be compared with its competition.
Maybe there's a moral here.
Hi Kevin,
good idea, I'm going to have lunch with him tomorrow... ;-)
Cheers, Juergen
Shelby Beach
2013-01-14 19:22:31 UTC
Permalink
Juergen,

Total bummer... your experience really sounds awful (and painful). Hope
you're feeling (and typing) better soon. Just remember, everything happens
for a reason; the cup probably contained high levels of lead !

Take care,
Shelby
Juergen
2013-01-15 15:06:06 UTC
Permalink
Hi Shelby, All,

thanks a lot for the many good wishes! (and sorry for being not very responsive these days, typing is really a mess with one hand)

Cheers, Juergen
Juergen,
Total bummer... your experience really sounds awful (and painful). Hope
you're feeling (and typing) better soon. Just remember, everything happens
for a reason; the cup probably contained high levels of lead !
Take care,
Shelby
dhdurgee
2013-02-08 12:55:17 UTC
Permalink
Post by Mark Morgan Lloyd
Post by Tony Harminc
I was browsing the old VMSHARE database looking for something else,
=========================
APL trivia: what do you get from (floor)(slash)(iota)0? (That's
the numeric digit zero). Hint: I don't think there's any way to
derive this from the definitions of the individual operators. Bonus
question: what do you get if you replace (floor) by (ceiling)?
(Also known as minimum and maximum, and downstile and upstile.)
*** APPENDED 11/22/88 18:01:13 BY FNC/WHT3 ***
They give you the largest and smallest real numbers that your APL
implementation can work with.
*** APPENDED 11/23/88 20:07:15 BY .BL ***
Right, Barry. I only just recently found out about this.
*** APPENDED 11/24/88 14:17:15 BY FNC/WHT3 ***
(floor)(slash)(iota)0 is asking for the minimum of an empty set, which
is (matchematically-speaking) undefined. (The minimum of a set has to be
a member of the set, and an empty set has no members.) The generalization
of minimum to more general sets is "greatest lower bound" (or glb).
The glb of the empty set is +infinity, so APLs choice of the largest positive
number is certainly reasonable (it is the greatest lower bound that APL
can express, anyway).
Interesting. Is this the only case where an empty (zero-length) array is
significant? I'm obviously going to have to check how my own APL
implementation evaluates this.
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
You will get identity elements as a result in many cases:

+/&#9075;0 &#8592;&#8594; 0
×/&#9075;0 &#8592;&#8594; 1
-/&#9075;0 &#8592;&#8594; 0
÷/&#9075;0 &#8592;&#8594; 1
</&#9075;0 &#8592;&#8594; 0
&#8804;/&#9075;0 &#8592;&#8594; 1
=/&#9075;0 &#8592;&#8594; 1
&#8805;/&#9075;0 &#8592;&#8594; 1
Post by Mark Morgan Lloyd
/&#9075;0 &#8592;&#8594; 0
&#8800;/&#9075;0 &#8592;&#8594; 0
&#8744;/&#9075;0 &#8592;&#8594; 0
&#8743;/&#9075;0 &#8592;&#8594; 1
*/&#9075;0 &#8592;&#8594; 1
&#9017;/&#9075;0 &#8592;&#8594; 1

Hope that helps.

Dave
Mark Morgan Lloyd
2013-02-08 16:02:31 UTC
Permalink
Post by dhdurgee
Post by Mark Morgan Lloyd
Post by Tony Harminc
(floor)(slash)(iota)0 is asking for the minimum of an empty set, which
is (matchematically-speaking) undefined. (The minimum of a set has to be
a member of the set, and an empty set has no members.) The generalization
of minimum to more general sets is "greatest lower bound" (or glb).
The glb of the empty set is +infinity, so APLs choice of the largest positive
number is certainly reasonable (it is the greatest lower bound that APL
can express, anyway).
Interesting. Is this the only case where an empty (zero-length) array is
significant? I'm obviously going to have to check how my own APL
implementation evaluates this.
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
+/&#9075;0 &#8592;&#8594; 0
×/&#9075;0 &#8592;&#8594; 1
-/&#9075;0 &#8592;&#8594; 0
÷/&#9075;0 &#8592;&#8594; 1
</&#9075;0 &#8592;&#8594; 0
&#8804;/&#9075;0 &#8592;&#8594; 1
=/&#9075;0 &#8592;&#8594; 1
&#8805;/&#9075;0 &#8592;&#8594; 1
Post by Mark Morgan Lloyd
/&#9075;0 &#8592;&#8594; 0
&#8800;/&#9075;0 &#8592;&#8594; 0
&#8744;/&#9075;0 &#8592;&#8594; 0
&#8743;/&#9075;0 &#8592;&#8594; 1
*/&#9075;0 &#8592;&#8594; 1
&#9017;/&#9075;0 &#8592;&#8594; 1
Hope that helps.
Dave
So I think what that's saying is that (function)(slash) has to be seeded
with a function-defined initial value, specifically to accommodate the
case where the array is empty.
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
dhdurgee
2013-02-08 17:05:25 UTC
Permalink
Post by Mark Morgan Lloyd
Post by dhdurgee
Post by Mark Morgan Lloyd
Post by Tony Harminc
(floor)(slash)(iota)0 is asking for the minimum of an empty set, which
is (matchematically-speaking) undefined. (The minimum of a set has to be
a member of the set, and an empty set has no members.) The generalization
of minimum to more general sets is "greatest lower bound" (or glb).
The glb of the empty set is +infinity, so APLs choice of the largest positive
number is certainly reasonable (it is the greatest lower bound that APL
can express, anyway).
Interesting. Is this the only case where an empty (zero-length) array is
significant? I'm obviously going to have to check how my own APL
implementation evaluates this.
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
+/&#9075;0 &#8592;&#8594; 0
×/&#9075;0 &#8592;&#8594; 1
-/&#9075;0 &#8592;&#8594; 0
÷/&#9075;0 &#8592;&#8594; 1
</&#9075;0 &#8592;&#8594; 0
&#8804;/&#9075;0 &#8592;&#8594; 1
=/&#9075;0 &#8592;&#8594; 1
&#8805;/&#9075;0 &#8592;&#8594; 1
Post by Mark Morgan Lloyd
/&#9075;0 &#8592;&#8594; 0
&#8800;/&#9075;0 &#8592;&#8594; 0
&#8744;/&#9075;0 &#8592;&#8594; 0
&#8743;/&#9075;0 &#8592;&#8594; 1
*/&#9075;0 &#8592;&#8594; 1
&#9017;/&#9075;0 &#8592;&#8594; 1
Hope that helps.
Dave
So I think what that's saying is that (function)(slash) has to be seeded
with a function-defined initial value, specifically to accommodate the
case where the array is empty.
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
Yes. In fact, if you take a look at NARS2000 the feature is included:

http://wiki.nars2000.org/index.php/System_Labels

Dave

Loading...