Running APL\360 on OS/360-MVT 21.8F: MVT for APL Version 2.00 available

[Juergen]

Hi All,

- Second will be an update of the mvt4apl "ready to install"
system containing all the above workspaces and enhancements
from feedback received on the 1.00 version.
- Third will be in cooperation with the Computer History
Museum a "ready to use" system, where the APL licensed code
will be hosted at the Museum's website.

Well, today I'm publishing MVT for APL Version 2.00 (mvt4apl-2.00) which is both in one:

While updating, restructuring and automating mvt4apl-1.00 to create an easy to handle base for the "ready to use" system I realized that the techniques used for that could easily be extended to fully automate the installation process too, thus allowing the "ready to install" and the "ready to use" systems to be identical.

So, all you need is a Windows or Linux system, the MVT for APL Version 2.00 distribution from

http://wotho.ethz.ch/mvt4apl-2.00.zip

and the APL\360 source from the Museum (link is published in the MVT for APL documentation).

All you need to do is

- Install the APL font, predefined connection parameters and very few minor settings on your Windows or Linux system (and that's the only manual work you need to do!)

- Unzip the source you downloaded from the museum

- Start the system by executing a single script.

- Sit back, relax and wait for two APL\360 windows to pop up

There are no interactions with Hercules or OS/360 necessary. The need for knowhow in these areas has been completely eliminated, making MVT for APL a true ready to use APL\360 system while still not containing a single byte of APL\360 licensed code.

Specific features are:

- A ready to run OS/360-MVT 21.8F system configured to accommodate APL\360 but not containing any copyrighted code.
- An automated procedure to build APL\360 and the MVT supervisor calls it relies on from source.
- An automated operator (APLPILOT) for the OS/360-MVT system.
- A minimal automated operator for the recording terminal, which is intended for server type Linux systems to enable deployment of AaaS (APL as a Service).
- The MVT for APL Version 2.00 User's Manual.
- A partial reimplementation of the OPFNS workspace with sufficient functionality to operate APL\360 on emulated hardware.
- A comprehensive public workspace library which has been imported from APL\MTS (thanks Phil!)

Acknowledgements:
=================

- Len Shustek, Chairman of the Board of Trustees, Computer History Museum, Mountain View, went through 10 years of persistent negotiations with IBM to make the impossible happen: Obtain a license to make the APL\360 source code available to the public for non-commercial use.
- Brian and Barry Silverman shared many insights they gained during their 1998 APL\360 resurrection project, especially on how to handcraft a library structure on DASD. This greatly helped overcome the chicken-egg problem of how to create an initial library setup without having the original distribution tape available.
- Catherine Lathwell spread the word when the APL\360 source became available and provided the connection to Len Shustek.
- Max H. Parke provided the IBM 2741 terminal support: Having created the Hercules device driver for the 2741 and other asynchronous terminals attached to an IBM 2703 TCU, Max is most knowledgeable when it comes to implementing emulations of complex communications equipment and topologies. With the availability of APL\360 running on OS/360-MVT under Hercules he added the functionality and features required by APL\360 to the 2741 device support to provide a true generic implementation of the most commonly used APL terminal back in the APL\360 era.
- Tony Harminc made information about APL internal structures (workspaces, libraries, control blocks) available that was very helpful in creating the initial library setup.
- Jay Maynard's cookbook style MVT system generation instructions enabled getting up to speed with OS/360-MVT quickly.
- Kevin Leonard provides a lot of tools (namely PDS, COMPARE and REVIEW) and usability enhancements for OS/360-MVT on his website that helped transforming the MVT system initially meant as a runtime only environment into a veritable development system.
- Phil Roberts extracted the public library workspaces from APL\MTS. This was a major effort including installation of MTS and APL\MTS, exploring how to execute APL\MTS and how to print output, unlocking hidden functions, putting together some 4,000 APL statements to extract and finally print the full contents of the workspaces.
- and last but not least the Hercules developers who made this effort possible by providing this great piece of software.

Have Fun!

Cheers, Juergen

[winnow33]

I tried it on Win XP but ran into two issues. The first is that it needs msvcr100.dll to run. I found a copy and put it in the Windows directory and it seemed happy. But then the script complains of a JCL error at S APL360. I think the relevant log lines are:

225530 4000 22.55.30 IKJ052I TIME SHARING REGION 01 HAS STARTED
225530 4000 22.55.30 IKJ019I TSO HAS BEEN INITIALIZED
225532 0000 22.55.32 S BALLOON
225532 0000 22.55.32 MN SESS,T
225533 0000 22.55.33 MN SESS,T
225534 0000 22.55.34 S APL360
225534 0040 22.55.34 IEE132I START COMMAND DEV ALLOC ERR
225534 4000 22.55.34 IEF868I 00E WTR WAITING FOR WORK
225536 0000 22.55.36 P BALLOON
225536 4000 22.55.36 IEF868I 00E WTR WAITING FOR WORK
225540 0000 22.55.40 P TSO
225540 4000 22.55.40 IKJ078I TSO TSO TSO IS STOPPING

Tried it a number of times and it seemed not to be able to get past this point.

Post by Juergen
Hi All,

- Second will be an update of the mvt4apl "ready to install"
system containing all the above workspaces and enhancements
from feedback received on the 1.00 version.
- Third will be in cooperation with the Computer History
Museum a "ready to use" system, where the APL licensed code
will be hosted at the Museum's website.

While updating, restructuring and automating mvt4apl-1.00 to create an easy to handle base for the "ready to use" system I realized that the techniques used for that could easily be extended to fully automate the installation process too, thus allowing the "ready to install" and the "ready to use" systems to be identical.
So, all you need is a Windows or Linux system, the MVT for APL Version 2.00 distribution from
http://wotho.ethz.ch/mvt4apl-2.00.zip
and the APL\360 source from the Museum (link is published in the MVT for APL documentation).
All you need to do is
- Install the APL font, predefined connection parameters and very few minor settings on your Windows or Linux system (and that's the only manual work you need to do!)
- Unzip the source you downloaded from the museum
- Start the system by executing a single script.
- Sit back, relax and wait for two APL\360 windows to pop up
There are no interactions with Hercules or OS/360 necessary. The need for knowhow in these areas has been completely eliminated, making MVT for APL a true ready to use APL\360 system while still not containing a single byte of APL\360 licensed code.
- A ready to run OS/360-MVT 21.8F system configured to accommodate APL\360 but not containing any copyrighted code.
- An automated procedure to build APL\360 and the MVT supervisor calls it relies on from source.
- An automated operator (APLPILOT) for the OS/360-MVT system.
- A minimal automated operator for the recording terminal, which is intended for server type Linux systems to enable deployment of AaaS (APL as a Service).
- The MVT for APL Version 2.00 User's Manual.
- A partial reimplementation of the OPFNS workspace with sufficient functionality to operate APL\360 on emulated hardware.
- A comprehensive public workspace library which has been imported from APL\MTS (thanks Phil!)
=================
- Len Shustek, Chairman of the Board of Trustees, Computer History Museum, Mountain View, went through 10 years of persistent negotiations with IBM to make the impossible happen: Obtain a license to make the APL\360 source code available to the public for non-commercial use.
- Brian and Barry Silverman shared many insights they gained during their 1998 APL\360 resurrection project, especially on how to handcraft a library structure on DASD. This greatly helped overcome the chicken-egg problem of how to create an initial library setup without having the original distribution tape available.
- Catherine Lathwell spread the word when the APL\360 source became available and provided the connection to Len Shustek.
- Max H. Parke provided the IBM 2741 terminal support: Having created the Hercules device driver for the 2741 and other asynchronous terminals attached to an IBM 2703 TCU, Max is most knowledgeable when it comes to implementing emulations of complex communications equipment and topologies. With the availability of APL\360 running on OS/360-MVT under Hercules he added the functionality and features required by APL\360 to the 2741 device support to provide a true generic implementation of the most commonly used APL terminal back in the APL\360 era.
- Tony Harminc made information about APL internal structures (workspaces, libraries, control blocks) available that was very helpful in creating the initial library setup.
- Jay Maynard's cookbook style MVT system generation instructions enabled getting up to speed with OS/360-MVT quickly.
- Kevin Leonard provides a lot of tools (namely PDS, COMPARE and REVIEW) and usability enhancements for OS/360-MVT on his website that helped transforming the MVT system initially meant as a runtime only environment into a veritable development system.
- Phil Roberts extracted the public library workspaces from APL\MTS. This was a major effort including installation of MTS and APL\MTS, exploring how to execute APL\MTS and how to print output, unlocking hidden functions, putting together some 4,000 APL statements to extract and finally print the full contents of the workspaces.
- and last but not least the Hercules developers who made this effort possible by providing this great piece of software.
Have Fun!
Cheers, Juergen

[Juergen]

Post by winnow33
I tried it on Win XP but ran into two issues.

Hi Winnow,

Post by winnow33
The first is that it needs msvcr100.dll to run.

I didn't want to engage in having the installation script find out whether the user has a valid Microsoft runtime library msvcr100.dll installed, which is why I simply provide the download link in the User's Manual at the point, where the error will occur if it isn't installed: In chapter "Start the APL\360 System" on page 8.

So far so good: Sooner or later the user will find out what the problem is, either by reading the User's Manual :-) or by "found a copy and put it in the Windows directory" :-(, and continue...

Post by winnow33
225534 0000 22.55.34 S APL360
225534 0040 22.55.34 IEE132I START COMMAND DEV ALLOC ERR

The installer logic is pretty simple: It remembers that it did already run once by placing a file named "status" in the aplinst folder. If, on subsequent calls, this file is found the installer doesn't get called again.

The point here is that Hercules always ends with RC=0 regardless what happened "inside", which is why I didn't bother to check its return code (I'm testing under Linux and on Linux the missing DLL situation cannot occur). So, in the given situation the installer didn't get aborted from the non zero Hercules return code created by Windows upon terminating Hercules due to the missing DLL. This means it ran 'til the very end and created its status file.

Then you resolved the DLL issue and tried again: The installer doesn't get called because the status file suggests that APL\360 is installed already. Well, but it isn't because the DLL issue prevented it. Consequently you get an IEE132I because the APL\360 runtime library doesn't exist.

(:-(\/

I fixed the logic of the installer now such that it terminates on a none zero Hercules return code (Windows only, Linux I still think it's not necessary).

I've updated yesterday's version in place (i.e. same version number, same download link) and would appreciate if you download it again, using the same installation sequence (i.e. remove you msvcr100.dll, then put it back in place after the error message made you aware of the "problem", and rerun the apl360.bat script). Provided you've matched all other installation prereqs I'm sure that it will work now.

Of course you also can continue on your existing download by simply deleting the "status" file in folder aplinst and rerunning the apl360.bat script.

Cheers, Juergen

[winnow33]

Great job!

Works both ways as you said, deleting the status file or by using the new installer and downloading the dll after the first run.

Post by Juergen

Post by winnow33
I tried it on Win XP but ran into two issues.

Hi Winnow,

Post by winnow33
The first is that it needs msvcr100.dll to run.

I didn't want to engage in having the installation script find out whether the user has a valid Microsoft runtime library msvcr100.dll installed, which is why I simply provide the download link in the User's Manual at the point, where the error will occur if it isn't installed: In chapter "Start the APL\360 System" on page 8.
So far so good: Sooner or later the user will find out what the problem is, either by reading the User's Manual :-) or by "found a copy and put it in the Windows directory" :-(, and continue...

Post by winnow33
225534 0000 22.55.34 S APL360
225534 0040 22.55.34 IEE132I START COMMAND DEV ALLOC ERR

The installer logic is pretty simple: It remembers that it did already run once by placing a file named "status" in the aplinst folder. If, on subsequent calls, this file is found the installer doesn't get called again.
The point here is that Hercules always ends with RC=0 regardless what happened "inside", which is why I didn't bother to check its return code (I'm testing under Linux and on Linux the missing DLL situation cannot occur). So, in the given situation the installer didn't get aborted from the non zero Hercules return code created by Windows upon terminating Hercules due to the missing DLL. This means it ran 'til the very end and created its status file.
Then you resolved the DLL issue and tried again: The installer doesn't get called because the status file suggests that APL\360 is installed already. Well, but it isn't because the DLL issue prevented it. Consequently you get an IEE132I because the APL\360 runtime library doesn't exist.
(:-(\/
I fixed the logic of the installer now such that it terminates on a none zero Hercules return code (Windows only, Linux I still think it's not necessary).
I've updated yesterday's version in place (i.e. same version number, same download link) and would appreciate if you download it again, using the same installation sequence (i.e. remove you msvcr100.dll, then put it back in place after the error message made you aware of the "problem", and rerun the apl360.bat script). Provided you've matched all other installation prereqs I'm sure that it will work now.
Of course you also can continue on your existing download by simply deleting the "status" file in folder aplinst and rerunning the apl360.bat script.
Cheers, Juergen

[Juergen]

Post by winnow33
Great job!
Works both ways as you said, deleting the status file or by
using the new installer and downloading the dll after the
first run.

Thanks for cross checking!

Cheers, Juergen

[verrilli]

Juergen,
That sounds like a big improvement! I especially like the automated startup of APL.
If I already have the version 1 installed on linux with also the libraries installed plus some user workspaces, how can I upgrade to version 2.0?

Colin

[Juergen]

Post by verrilli
Juergen,
That sounds like a big improvement! I especially
like the automated startup of APL.
If I already have the version 1 installed on linux
with also the libraries installed plus some user
workspaces, how can I upgrade to version 2.0?
Colin

Hi Colin

I recommend the following procedure:

1. Create an empty nolabel tape: hetinit -d -n anyname.aws
2. Logon to APMAINT on your version 1.00 system and submit job APLDUMP from APMAINT.CNTL
3. When prompted mount the tape created in step 1. on drive 280: devinit 280 <your path>/anyname.aws
4. Shutdown your version 1.00 system
5. Unzip the mvt4apl-2.00.zip archive
6. Replace tapes/apllib.aws with the tape created in step 1.
7. Perform the version 2.00 installation as described in the User's Manual

This sequence will bring up the version 2 system with exactly the users, libraries and workspaces you had in your version 1 system. The libraries that come with version 2 are identical to those I distributed standalone earlier, with the exception of two additional news items in the APLNOW storyline of workspace 1 NEWS.

If you want to merge that into your system (fully optional, it's documentation only!), you can run job RETRIEVE from APMAINT.CNTL of the version 2 system, which comes preconfigured to select 1 NEWS only: RETRIEVE will ask for a tape and then you simply mount the original apllib.aws tape that came with version 2.

Cheers, Juergen

[verrilli]

Juergen,
Thanks for the procedure.
I had a small glitch with hetinit as it couldn't find the shared libraries for Hercules utilities. I added the path to LD_LIBRARY_PATH. Not sure if that is the correct way. It seemed to create a file in the tapes directory.
I then ran the APLDUMP job and got this in the master console:
$ 3.22.30 JOB 13 -- APLDUMP -- BEGINNING EXEC - INIT 1 - CLASS A
- 3.22.30 JOB 13 IEF403I APLDUMP STARTED TIME=03.22.30
* 3.22.30 JOB 13 IEF233A M 280,APLLIB,,APLDUMP,SS
3.22.30 JOB 13 APL INVALID -- APL RUNNING DUMP 10000
* 3.22.30 JOB 13 04 APL INVALID -- APL RUNNING DUMP 10000
The "INVALID" didn't look too good.
I did the devinit 280 in the Hercules console anyway, but not much happened. the file is small in the tapes directory:

[***@colin-linux tapes]$ ls -l
total 696
-rw-r--r--. 1 colin colin 53448 Nov 3 12:13 apllib.aws
-rw-rw-r--. 1 colin colin 650610 Feb 26 15:02 APL_LIBRARY_DUMP_13.057.aws
-rw-r-----. 1 colin colin 12 Apr 24 22:20 v1_backup.aws

so I don't think the backup occurred. Suggestions?

Post by Juergen

Post by verrilli
Juergen,
That sounds like a big improvement! I especially
like the automated startup of APL.
If I already have the version 1 installed on linux
with also the libraries installed plus some user
workspaces, how can I upgrade to version 2.0?
Colin

Hi Colin
1. Create an empty nolabel tape: hetinit -d -n anyname.aws
2. Logon to APMAINT on your version 1.00 system and submit job APLDUMP from APMAINT.CNTL
3. When prompted mount the tape created in step 1. on drive 280: devinit 280 <your path>/anyname.aws
4. Shutdown your version 1.00 system
5. Unzip the mvt4apl-2.00.zip archive
6. Replace tapes/apllib.aws with the tape created in step 1.
7. Perform the version 2.00 installation as described in the User's Manual
This sequence will bring up the version 2 system with exactly the users, libraries and workspaces you had in your version 1 system. The libraries that come with version 2 are identical to those I distributed standalone earlier, with the exception of two additional news items in the APLNOW storyline of workspace 1 NEWS.
If you want to merge that into your system (fully optional, it's documentation only!), you can run job RETRIEVE from APMAINT.CNTL of the version 2 system, which comes preconfigured to select 1 NEWS only: RETRIEVE will ask for a tape and then you simply mount the original apllib.aws tape that came with version 2.
Cheers, Juergen

[Juergen]

Post by verrilli
Juergen,
Thanks for the procedure.
I had a small glitch with hetinit as it couldn't find the
shared libraries for Hercules utilities. I added the path
to LD_LIBRARY_PATH. Not sure if that is the correct way.
It seemed to create a file in the tapes directory.

Hi Colin,

yes, that's of course correct... I didn't mention it, because one can equivalently use the Hercules utilities from a global installation (i.e. installed as part of the Linux distribution), which I assumed you'd have on your system. The utilities (hetinit, dasdinit, etc.) don't have any APL specific modifications. Anyway: I'm glad you found out how to do it.

Post by verrilli
$ 3.22.30 JOB 13 -- APLDUMP -- BEGINNING EXEC - INIT 1 - CLASS A
- 3.22.30 JOB 13 IEF403I APLDUMP STARTED TIME=03.22.30
* 3.22.30 JOB 13 IEF233A M 280,APLLIB,,APLDUMP,SS
3.22.30 JOB 13 APL INVALID -- APL RUNNING DUMP 10000
* 3.22.30 JOB 13 04 APL INVALID -- APL RUNNING DUMP 10000
The "INVALID" didn't look too good.
I did the devinit 280 in the Hercules console anyway,
total 696
-rw-r--r--. 1 colin colin 53448 Nov 3 12:13 apllib.aws
-rw-rw-r--. 1 colin colin 650610 Feb 26 15:02 APL_LIBRARY_DUMP_13.057.aws
-rw-r-----. 1 colin colin 12 Apr 24 22:20 v1_backup.aws
so I don't think the backup occurred. Suggestions?

Well, that's clear, most APL utility commands cannot run concurrently with APL, which is what the above message says: It refuses to run a DUMP while APL is running (admittedly the text isn't exactly rhetorically brilliant).

So, just shut down APL\360, then shut down MVT, then re-IPL MVT but don't start APL\360. Then you should be able to run APLDUMP.

Cheers, Juergen

[verrilli]

Juergen,
That worked!
And the rest of your procedure worked smoothly including the whole automated installation. Nice work!

Colin.

Post by Juergen

Post by verrilli
$ 3.22.30 JOB 13 -- APLDUMP -- BEGINNING EXEC - INIT 1 - CLASS A
- 3.22.30 JOB 13 IEF403I APLDUMP STARTED TIME=03.22.30
* 3.22.30 JOB 13 IEF233A M 280,APLLIB,,APLDUMP,SS
3.22.30 JOB 13 APL INVALID -- APL RUNNING DUMP 10000
* 3.22.30 JOB 13 04 APL INVALID -- APL RUNNING DUMP 10000
The "INVALID" didn't look too good.
I did the devinit 280 in the Hercules console anyway,
total 696
-rw-r--r--. 1 colin colin 53448 Nov 3 12:13 apllib.aws
-rw-rw-r--. 1 colin colin 650610 Feb 26 15:02 APL_LIBRARY_DUMP_13.057.aws
-rw-r-----. 1 colin colin 12 Apr 24 22:20 v1_backup.aws
so I don't think the backup occurred. Suggestions?

Well, that's clear, most APL utility commands cannot run concurrently with APL, which is what the above message says: It refuses to run a DUMP while APL is running (admittedly the text isn't exactly rhetorically brilliant).
So, just shut down APL\360, then shut down MVT, then re-IPL MVT but don't start APL\360. Then you should be able to run APLDUMP.
Cheers, Juergen

[Juergen]

Post by verrilli
Juergen,
That worked!
And the rest of your procedure worked smoothly including the
whole automated installation. Nice work!

thanks for the feedback!

In the meantime I've quite a bit of positive feedback, particularly from people without OS and Hercules background, i.e. "APL only" people. This shows that the MVT for APL distribution is now at a level that might be considered final, at least from a software preservation point of view.

So, this might be the point in time, where one could leave "authentic mode", trying to modernize the system. In a first step this would require creation of a comprehensive regression test suite to be used to verify enhancements against the base APL\360 functionality we now have available. Further steps could then for example follow the road the original product took: Port it to CMS (alternatively TSO), allow 24-bit workspaces, introduce shared variables and a basic set of SV processors, add 3270 (graphics!) support, finally ending up at something that might look similar to APLSV.

Post by verrilli
From what I've seen during the resurrection work of APL\360 a modernization up to a level similar to APLSV would surely be doable but the effort would be massive. Given that, plus the fact that the result would still be bound to the restrictive APL\360 license, makes it very questionable whether going ahead would make sense.

So, for now I prefer waiting for yet another wonder. Perhaps someone still has an APLSV (or later, or even different vendor like I.P. Sharp) distribution around and dares giving it to the computer history museum? Eventually Len Shustek might succeed getting it released in a similar way he did with APL\360... well, I'm of course dreaming ;-)

Until this dream eventually comes true: Have fun playing with APL\360!

Cheers, Juergen

[Mark Morgan Lloyd]

Post by Juergen

Post by verrilli
Juergen,
That worked!
And the rest of your procedure worked smoothly including the
whole automated installation. Nice work!

thanks for the feedback!
In the meantime I've quite a bit of positive feedback, particularly from people without OS and Hercules background, i.e. "APL only" people. This shows that the MVT for APL distribution is now at a level that might be considered final, at least from a software preservation point of view.
Until this dream eventually comes true: Have fun playing with APL\360!

Minor niggle: doc p29 has

The jobs to generate the above tools can be found in SYS1.SETUP.ASM as
follows:
SYS1.SETUP.CNTL -----

Is the location in the first line correct?

I'm hoping to install it when time permits so that I can check my 2741
emulator against it.

[Juergen]

Post by Mark Morgan Lloyd

Post by Juergen

Post by verrilli
Juergen,
That worked!
And the rest of your procedure worked smoothly including the
whole automated installation. Nice work!

thanks for the feedback!
In the meantime I've quite a bit of positive feedback, particularly from people without OS and Hercules background, i.e. "APL only" people. This shows that the MVT for APL distribution is now at a level that might be considered final, at least from a software preservation point of view.
Until this dream eventually comes true: Have fun playing with APL\360!

Minor niggle: doc p29 has
The jobs to generate the above tools can be found in SYS1.SETUP.ASM as
SYS1.SETUP.CNTL -----
Is the location in the first line correct?

Thanks for the comment! That's a copy and paste error: It should read SYS1.SETUP.CNTL in the first line.

There was another feedback concerning a small typo, and one requesting a chapter on how to install on a headless box, i.e. client and server running on different systems.

If there comes up a necessity for an update due to bug fixing or technical enhancements I'll include an updated manual as well. But for now, due to time constraints on my side, I'm leaving it as it is.

Cheers, Juergen

[Greg B]

Greetings,

I had absolutely no problem installing and using this under Windows 7.
However, when I went to install under Linux on a non-'86 type processor, I
recognized that the distribution package includes x86 binaries so I could
not move forward. Is there a future plan to distribute a package compilable
for other platforms?

Thanks,
Greg B



--
View this message in context: http://hercules390.996247.n3.nabble.com/Running-APL-360-on-OS-360-MVT-21-8F-MVT-for-APL-Version-2-00-available-tp39964p40228.html
Sent from the Hercules390 - General mailing list archive at Nabble.com.

[Juergen]

Post by Greg B
Greetings,
I had absolutely no problem installing and using this
under Windows 7. However, when I went to install under
Linux on a non-'86 type processor, I recognized that the
distribution package includes x86 binaries so I could
not move forward. Is there a future plan to distribute
a package compilable for other platforms?

Hi Greg,

supporting additional processor architectures under Linux wasn't exactly on the "roadmap" up to now. But it wouldn't be complicated at all: One would have to build the Hercules and the PuTTY binaries for that architecture and extend the startup scripts (apl360, apl360_client, os360-mvt and start_herc, and perhaps some of the automation handlers) to recognize the architecture and set the path to the binaries and libraries correctly. That should basically do the trick ;-)

What is the specific architecture you're talking about?

Cheers, Juergen

[Greg B]

Post by Juergen
Hi Greg,
supporting additional processor architectures under Linux wasn't exactly
on the "roadmap" up to now. But it wouldn't be complicated at all: One
would have to build the Hercules and the PuTTY binaries for that
architecture and extend the startup scripts (apl360, apl360_client,
os360-mvt and start_herc, and perhaps some of the automation handlers) to
recognize the architecture and set the path to the binaries and libraries
correctly. That should basically do the trick ;-)
What is the specific architecture you're talking about?
Cheers, Juergen

I found that the current version of Debian Linux includes the Hercules
package. Debian runs on the Raspberry Pi (yes I know it's tiny , slow, and
limited). However, with some searching, I found that others had successfully
run Hercules on this platform. One thought leads to another, so why not run
APL\360 on the Pi. A minimum implementation for sure, but one that would be
a bit more than just novel I think. I don't have a lot of time, but I'll
give a try at doing the port to that environment, but may call for help if I
get stuck.

Greg



--
View this message in context: http://hercules390.996247.n3.nabble.com/Running-APL-360-on-OS-360-MVT-21-8F-MVT-for-APL-Version-2-00-available-tp39964p40233.html
Sent from the Hercules390 - General mailing list archive at Nabble.com.

[Tony Harminc]

Post by Greg B
I found that the current version of Debian Linux includes the Hercules
package. Debian runs on the Raspberry Pi (yes I know it's tiny , slow, and
limited). However, with some searching, I found that others had successfully
run Hercules on this platform. One thought leads to another, so why not run
APL\360 on the Pi. A minimum implementation for sure, but one that would be
a bit more than just novel I think. I don't have a lot of time, but I'll
give a try at doing the port to that environment, but may call for help if I
get stuck.

It might make sense to use the "standalone" version of APL\360 for
such a small platform. (I put standalone in quotes, because that
version starts up under DOS/360, and once it's up, overlays the DOS
supervisor with I/O buffers.) Of course this isn't all ready to go
like Juergen's great MVT work, but it almost certainly would have
lower overhead than the MVT version.

Tony H.

[Juergen]

Post by Tony Harminc

Post by Greg B
I found that the current version of Debian Linux includes
the Hercules package. Debian runs on the Raspberry Pi (yes
I know it's tiny , slow, and limited). However, with some
searching, I found that others had successfully run Hercules
on this platform. One thought leads to another, so why not run
APL\360 on the Pi. A minimum implementation for sure, but one
that would be a bit more than just novel I think. I don't
have a lot of time, but I'll give a try at doing the port
to that environment, but may call for help if I get stuck.

Of course I'll provide all help I can.

To start look at folder software\Hercules: It contains all patches that need to be applied above the Hercules Sandhawk snapshot from 2012-11-30. Later snapshots may contain some of these patches already.

The PuTTY source together with the patch needed to enable it to connect to the Hercules console port can be found in folder PuTTY-0.62_for_Hercules\source.

Once you succeeded to build both, Hercules and PuTTY, you're almost ready to go: Some fiddling with the scripts as I mentioned in the previous post and it should work.

Post by Tony Harminc
It might make sense to use the "standalone" version of APL\360 for
such a small platform. (I put standalone in quotes, because that
version starts up under DOS/360, and once it's up, overlays the DOS
supervisor with I/O buffers.) Of course this isn't all ready to go
like Juergen's great MVT work, but it almost certainly would have
lower overhead than the MVT version.

yes, Tony, that's true: The standalone version would run with lower overhead. But:

- The source the Computer History Museum provides is for the MVT/MFT version only. There is no chance to build to build the standalone or the DOS version from that source. In the beginning I assumed that we have the source for all environments, so in older posts this erroneous assumption had been discussed.

- From my point of view even a Pi should be able to cope with a full blown MVT system. If necessary one could reduce main memory to around 512K and refrain from starting TCAM, TSO and HASP, which would reduce overhead to a minimum.

Cheers, Juergen

[Tony Harminc]

Post by Juergen
- The source the Computer History Museum provides is for the MVT/MFT version only. There is no chance to build to build the standalone or the DOS version from that source. In the beginning I assumed that we have the source for all environments, so in older posts this erroneous assumption had been discussed.

Ah - my mistake. I had thought that the DOS source was included. Tant pis...

Post by Juergen
- From my point of view even a Pi should be able to cope with a full blown MVT system. If necessary one could reduce main memory to around 512K and refrain from starting TCAM, TSO and HASP, which would reduce overhead to a minimum.

Indeed. And I suppose APL routinely uses none of the expensive MVT
services, like SYSOUT (or allocation in general). But still, I think
the startup (both MVT IPL and APL itself starting) will be much
slower.

Tony H.

[Juergen]

Post by Tony Harminc

Post by Juergen
yes, Tony, that's true: The standalone version would run
- The source the Computer History Museum provides is for
the MVT/MFT version only. There is no chance to build to
build the standalone or the DOS version from that source.
In the beginning I assumed that we have the source for all
environments, so in older posts this erroneous assumption
had been discussed.

Ah - my mistake. I had thought that the DOS source was
included. Tant pis...

Post by Juergen
- From my point of view even a Pi should be able to cope
with a full blown MVT system. If necessary one could reduce
main memory to around 512K and refrain from starting TCAM,
TSO and HASP, which would reduce overhead to a minimum.

Indeed. And I suppose APL routinely uses none of the expensive
MVT services, like SYSOUT (or allocation in general). But still,
I think the startup (both MVT IPL and APL itself starting) will
be much slower.

Yes, it basically runs standalone and uses MVT services only to avoid having to use MVT services ;-).

I'm curious to see how it will perform on a Pi... but I really don't expect it being slow. Startup on my 2.4 GHz Intel PC under Windows 7 takes 38 seconds, 30 of which being eaten up by pauses I introduced to get the automation as stable as possible.

Cheers, Juergen

[Mark Morgan Lloyd]

Post by Juergen
Once you succeeded to build both, Hercules and PuTTY, you're almost ready to go: Some fiddling with the scripts as I mentioned in the previous post and it should work.

Post by Tony Harminc
It might make sense to use the "standalone" version of APL\360 for
such a small platform. (I put standalone in quotes, because that
version starts up under DOS/360, and once it's up, overlays the DOS
supervisor with I/O buffers.) Of course this isn't all ready to go
like Juergen's great MVT work, but it almost certainly would have
lower overhead than the MVT version.

- The source the Computer History Museum provides is for the MVT/MFT version only. There is no chance to build to build the standalone or the DOS version from that source. In the beginning I assumed that we have the source for all environments, so in older posts this erroneous assumption had been discussed.

I thought I saw something in the source about VM. I wonder whether
that's doable, i.e. without the multiple terminal support etc.?

[Juergen]

Post by Mark Morgan Lloyd

Post by Juergen
- The source the Computer History Museum provides is for
the MVT/MFT version only. There is no chance to build to
build the standalone or the DOS version from that source.
In the beginning I assumed that we have the source for all
environments, so in older posts this erroneous assumption
had been discussed.

I thought I saw something in the source about VM. I wonder
whether that's doable, i.e. without the multiple terminal
support etc.?

No, the given source definitely has no "VM" intentions. But, afaik, the APLSV program product, which can be seen as closest successor of APL\360 in the line of IBM APL products, has gone that way: The APL\360 interpreter was first ported to CMS, then garbage collection was redesigned to enable 24-bit workspace sizes. This CMS version of APL\360 was then the base for the design of APLSV.

So, getting back to your question: Yes, a port to CMS is clearly doable. But without at least going after the workspace size extension too it would be clueless (i.e. why would one want to do this without having extensions in mind). The amount of work even for this "simple" extension is massive. The redesign of the workspace structure and the garbage collection definitely is heavy stuff. So, personally, I think it doesn't make much sense to go down this road.

Anyway: I don't want to demotivate anyone to try it ;-)

Cheers, Juergen

[Mark Morgan Lloyd]

Post by Juergen

Post by Mark Morgan Lloyd

Post by Juergen
- The source the Computer History Museum provides is for
the MVT/MFT version only. There is no chance to build to
build the standalone or the DOS version from that source.
In the beginning I assumed that we have the source for all
environments, so in older posts this erroneous assumption
had been discussed.

I thought I saw something in the source about VM. I wonder
whether that's doable, i.e. without the multiple terminal
support etc.?

No, the given source definitely has no "VM" intentions. But, afaik, the APLSV program product, which can be seen as closest successor of APL\360 in the line of IBM APL products, has gone that way: The APL\360 interpreter was first ported to CMS, then garbage collection was redesigned to enable 24-bit workspace sizes. This CMS version of APL\360 was then the base for the design of APLSV.
So, getting back to your question: Yes, a port to CMS is clearly doable. But without at least going after the workspace size extension too it would be clueless (i.e. why would one want to do this without having extensions in mind). The amount of work even for this "simple" extension is massive. The redesign of the workspace structure and the garbage collection definitely is heavy stuff. So, personally, I think it doesn't make much sense to go down this road.
Anyway: I don't want to demotivate anyone to try it ;-)

Thanks for the clarification :-) I think that from my position of
inexperience/ignorance I was ascribing more significance to internal
mention of CP67 than it deserved.

[verrilli]

I think that APL\360 never really was much more than an educational tool. I was writing a simple program the other day and forgot that the format operator was not available in APL\360. That made me remember that APL\360 had its serious shortcomings. But, I personally like that the original implementation of APL has been historically restored as close as possible to how it was back in the 70's. Very cool. Any further work on this project should be to make it an even closer historical experience to the original. Some ideas: Other libraries with sample programs? Better 2741 emulation? Typeball sound effects!? (I'll never forget the sound, and the smell for that matter, of the 2741 pounding away as fast as it could). I'd love to even find an old 2741 terminal and interface it to the emulator, but I guess they are unobtanium at this point. Best I could do was find an old IBM PC keyboard from the 80's and apply some IBM APL stickers to the keys. Not quite the same, but somewhat retro at least.

That being said, It would also be really cool to have a separate project implementing VM/CMS with APLSV. That was another experience which should be preserved. With APLSV, APL was made into a truly useful commercial product. I remember back in 1981 when I was an intern at IBM Kingston, they had a huge library of custom APL functions which translated high level hardware design language into low level BLDS card images. These were used to design the 8100 mini computers. This stuff was really used!

Colin

Post by Juergen
No, the given source definitely has no "VM" intentions. But, afaik, the APLSV program product, which can be seen as closest successor of APL\360 in the line of IBM APL products, has gone that way: The APL\360 interpreter was first ported to CMS, then garbage collection was redesigned to enable 24-bit workspace sizes. This CMS version of APL\360 was then the base for the design of APLSV.
So, getting back to your question: Yes, a port to CMS is clearly doable. But without at least going after the workspace size extension too it would be clueless (i.e. why would one want to do this without having extensions in mind). The amount of work even for this "simple" extension is massive. The redesign of the workspace structure and the garbage collection definitely is heavy stuff. So, personally, I think it doesn't make much sense to go down this road.
Anyway: I don't want to demotivate anyone to try it ;-)
Cheers, Juergen

[Gregg Levine]

Post by verrilli
I think that APL\360 never really was much more than an educational tool. I was writing a simple program the other day and forgot that the format operator was not available in APL\360. That made me remember that APL\360 had its serious shortcomings. But, I personally like that the original implementation of APL has been historically restored as close as possible to how it was back in the 70's. Very cool. Any further work on this project should be to make it an even closer historical experience to the original. Some ideas: Other libraries with sample programs? Better 2741 emulation? Typeball sound effects!? (I'll never forget the sound, and the smell for that matter, of the 2741 pounding away as fast as it could). I'd love to even find an old 2741 terminal and interface it to the emulator, but I guess they are unobtanium at this point. Best I could do was find an old IBM PC keyboard from the 80's and apply some IBM APL stickers to the keys. Not quite the same, but somewhat retro at least.
That being said, It would also be really cool to have a separate project implementing VM/CMS with APLSV. That was another experience which should be preserved. With APLSV, APL was made into a truly useful commercial product. I remember back in 1981 when I was an intern at IBM Kingston, they had a huge library of custom APL functions which translated high level hardware design language into low level BLDS card images. These were used to design the 8100 mini computers. This stuff was really used!
Colin

Post by Juergen
No, the given source definitely has no "VM" intentions. But, afaik, the APLSV program product, which can be seen as closest successor of APL\360 in the line of IBM APL products, has gone that way: The APL\360 interpreter was first ported to CMS, then garbage collection was redesigned to enable 24-bit workspace sizes. This CMS version of APL\360 was then the base for the design of APLSV.
So, getting back to your question: Yes, a port to CMS is clearly doable. But without at least going after the workspace size extension too it would be clueless (i.e. why would one want to do this without having extensions in mind). The amount of work even for this "simple" extension is massive. The redesign of the workspace structure and the garbage collection definitely is heavy stuff. So, personally, I think it doesn't make much sense to go down this road.
Anyway: I don't want to demotivate anyone to try it ;-)
Cheers, Juergen

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

Hello!
Not really. Selectric typewriters are available, and there are
available guides on turning one into a output only device. Turning it
into a input and output device, now that's a special case. I suspect
since the materials are available online concerning what's under the
hood, I believe it is almost doable.

And as it happens we'd need to explore the used equipment pages.
-----
Gregg C Levine gregg.drwho8-***@public.gmane.org
"This signature fought the Time Wars, time and again."

[Tony Harminc]

Post by Gregg Levine
Not really. Selectric typewriters are available, and there are
available guides on turning one into a output only device. Turning it
into a input and output device, now that's a special case. I suspect
since the materials are available online concerning what's under the
hood, I believe it is almost doable.
And as it happens we'd need to explore the used equipment pages.

There were several companies who bought Selectric mechanisms from IBM
- either true Selectric I/O printers, or just ordinary typewriters -
and made their own 2741-like terminals. The quality varied a lot, but
few were up to the real IBM ones, because there were at least a couple
of duty levels of the Selectric hardware, and the typewriter was not
up to intensive printing. I have one made by Novar that I bought used
for $300 around 1976. It uses the basic typewriter mechanism, and the
electronics and additional mechanics are quite different from IBM's. I
haven't fired it up in decades, and I suspect it needs a C3PO-style
bath in WD-40.

One of these days when I'm retired and have the time but no money...

Tony H.

[Dave]

Post by Gregg Levine

Post by verrilli
I think that APL\360 never really was much more than an educational tool. I was writing a simple program the other day and forgot that the format operator was not available in APL\360. That made me remember that APL\360 had its serious shortcomings. But, I personally like that the original implementation of APL has been historically restored as close as possible to how it was back in the 70's. Very cool. Any further work on this project should be to make it an even closer historical experience to the original. Some ideas: Other libraries with sample programs? Better 2741 emulation? Typeball sound effects!? (I'll never forget the sound, and the smell for that matter, of the 2741 pounding away as fast as it could). I'd love to even find an old 2741 terminal and interface it to the emulator, but I guess they are unobtanium at this point. Best I could do was find an old IBM PC keyboard from the 80's and apply some IBM APL stickers to the keys. Not quite the same, but somewhat retro at least.
That being said, It would also be really cool to have a separate project implementing VM/CMS with APLSV. That was another experience which should be preserved. With APLSV, APL was made into a truly useful commercial product. I remember back in 1981 when I was an intern at IBM Kingston, they had a huge library of custom APL functions which translated high level hardware design language into low level BLDS card images. These were used to design the 8100 mini computers. This stuff was really used!
Colin

Post by Juergen
No, the given source definitely has no "VM" intentions. But, afaik, the APLSV program product, which can be seen as closest successor of APL\360 in the line of IBM APL products, has gone that way: The APL\360 interpreter was first ported to CMS, then garbage collection was redesigned to enable 24-bit workspace sizes. This CMS version of APL\360 was then the base for the design of APLSV.
So, getting back to your question: Yes, a port to CMS is clearly doable. But without at least going after the workspace size extension too it would be clueless (i.e. why would one want to do this without having extensions in mind). The amount of work even for this "simple" extension is massive. The redesign of the workspace structure and the garbage collection definitely is heavy stuff. So, personally, I think it doesn't make much sense to go down this road.
Anyway: I don't want to demotivate anyone to try it ;-)
Cheers, Juergen

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

Hello!
Not really. Selectric typewriters are available, and there are
available guides on turning one into a output only device.

All the ones I have seen need a proper i/o writer not a typewriter.

Post by Gregg Levine
Turning it
into a input and output device, now that's a special case. I suspect
since the materials are available online concerning what's under the
hood, I believe it is almost doable.

Input device is probably easier. Magnets on the keyboard levers and Reed
Switches on a PCB underneath. I have an Electronic Composer which has
all this built in but is proportional and I don't want proportional.......

Post by Gregg Levine
And as it happens we'd need to explore the used equipment pages.
-----
"This signature fought the Time Wars, time and again."

Dave
G4UGM

[verrilli]

Hi,
I'm looking for a set or two of APL keyboard stickers. I know this is not the ideal place to post, but I figure there might be some APL users out there who could help.

I know about the APL FAQ but those sources seem to have dried up.

About a year ago I was able to order P/N SC33-0604-00 from IBM directly using a credit card, but now the site ( www.ibm.com/e-business/linkweb/publications/servlet/pbi.wss# ) no longer accepts credit cards. They only accept "customer number". I tried to obtain a customer number, but just ended up going around in circles with various support groups at IBM.

So does anybody know of a way an ordinary person can get these? Or is anybody who has a customer number willing to buy a couple for me and mail them to me?

The ironic thing is that I work for IBM and could order them for about $0.23 each, IF I had a valid business use. But I don't and it requires manager sign-off, so I'm out of luck. In the old days I would have been able to order under the radar, but the finance guys are in control of the company now, so...

Colin

[Mark Morgan Lloyd]

Post by verrilli
Hi,
I'm looking for a set or two of APL keyboard stickers. I know this is not the ideal place to post, but I figure there might be some APL users out there who could help.
I know about the APL FAQ but those sources seem to have dried up.
About a year ago I was able to order P/N SC33-0604-00 from IBM directly using a credit card, but now the site ( www.ibm.com/e-business/linkweb/publications/servlet/pbi.wss# ) no longer accepts credit cards. They only accept "customer number". I tried to obtain a customer number, but just ended up going around in circles with various support groups at IBM.
So does anybody know of a way an ordinary person can get these? Or is anybody who has a customer number willing to buy a couple for me and mail them to me?
The ironic thing is that I work for IBM and could order them for about $0.23 each, IF I had a valid business use. But I don't and it requires manager sign-off, so I'm out of luck. In the old days I would have been able to order under the radar, but the finance guys are in control of the company now, so...

This any use?
http://shop.hooleon.com/products/keyboards-stickers-emulations-apl

Otherwise it might be worth trawling suppliers like Dymo, in case any of
their label printers can do special characters and mark an arbitrary
outline which could be cut with a craft knife or (very) sharp scissors.

[verrilli]

Post by Mark Morgan Lloyd
This any use?
http://shop.hooleon.com/products/keyboards-stickers-emulations-apl

Mark,
Thanks for this pointer. Last time I had checked with them, they were sold out of this item.
I see that these are intended for key fronts. I'm not sure that would work on a laptop. The IBM stickers are transparent so they work well on the key top also.
But if I can't find a way to get the IBM ones, I'll give these a try.

Colin

[Tony Harminc]

Post by verrilli
Hi,
I'm looking for a set or two of APL keyboard stickers. I know this is not the ideal place to post, but I figure there might be some APL users out there who could help.
I know about the APL FAQ but those sources seem to have dried up.
About a year ago I was able to order P/N SC33-0604-00 from IBM directly using a credit card, but now the site ( www.ibm.com/e-business/linkweb/publications/servlet/pbi.wss# ) no longer accepts credit cards. They only accept "customer number". I tried to obtain a customer number, but just ended up going around in circles with various support groups at IBM.
So does anybody know of a way an ordinary person can get these? Or is anybody who has a customer number willing to buy a couple for me and mail them to me?
The ironic thing is that I work for IBM and could order them for about $0.23 each, IF I had a valid business use. But I don't and it requires manager sign-off, so I'm out of luck. In the old days I would have been able to order under the radar, but the finance guys are in control of the company now, so...

Heh - I have a personal customer number that I see from my old paper
files I last used in 1992. To my surprise the (bizarrely designed)
order entry page was happy to take it, but it finished up by saying
that the order would be forwarded to a customer rep for further
action, and then returned to me for final approval. A nice,
straighforward process...

So I ordered two sets, at CA$1.87 each (not bad, but there may be
shipping and handling charges), so we'll see what happens. I suspect
they will have long ago lost or thrown away my customer number, but If
they get here, one set is yours, and I'll be willing to order more. Or
if there's really a demand, I know a University wih a customer number
that has a bookstore; perhaps they could order and resell them.

Cheers... Tony H.

[verrilli]

Post by Tony Harminc
Heh - I have a personal customer number that I see from my old paper
files I last used in 1992. To my surprise the (bizarrely designed)
order entry page was happy to take it, but it finished up by saying
that the order would be forwarded to a customer rep for further
action, and then returned to me for final approval. A nice,
straighforward process...
So I ordered two sets, at CA$1.87 each (not bad, but there may be
shipping and handling charges), so we'll see what happens. I suspect
they will have long ago lost or thrown away my customer number, but If
they get here, one set is yours, and I'll be willing to order more. Or
if there's really a demand, I know a University wih a customer number
that has a bookstore; perhaps they could order and resell them.

Tony,
Thanks for the reply. And thanks for trying your old customer number! I hope it works, but from experience I know that the page will accept any number. In my case, About five days later a response came back saying it was invalid.

Let me know what happens
Colin

[wrljet]

Not useful to the conversation, but I had one of those customer
numbers back around 1980 when I was in school in Syracuse NY.

I needed it to buy a little package of weird IBM Bristol spline
wrenches to work on a Selectric typewriter based APL terminals
I had scrounged. I bought three of the terminals from a
fraternity house. Made one working one from the three.
They had a big PCB loaded with DTL chips. The wrenches came from
an IBM office in Syracuse.

I don't remember who made the terminals, but Datel somehow sticks
in my memory.

I still have the wrenches, but alas those Selectrics are long gone:
Loading Image...
Loading Image...

Bill

[wrljet]

I worked at STSC from 1981 to 1990, originally on VSAPL enhancements
(building NARS with Bob Smith), and later I was one of the developers of the from-scratch APL product we sold for Unix systems. I did the
386 protected mode port of that to run on MS-DOS.

Phelps Gates, author of the 16-bit APL*PLUS PC system, built the
front end editor for that. We thunked back and forth between
protected mode for the interpreter and real mode for his user
interface.

Anyway, to the point, here's a (not very good) picture of a set of
the original STSC APL*PLUS PC keyboard stickers.

Loading Image...

Bill

[dhdurgee]

I don't know if this helps, but APL keyboards are still available in both PS2 and USB versions from Unicomp. They are out at the moment but expect to have them available again in about three weeks. You can check at http://www.pckeyboard.com/ if this is of any use to you.

Dave

[Greg B]

Do you have a specific POC for the Unicomp APL keyboards? I contacted them
and the respones was that they were "considering" another run of the APL
keyboard.

Thanks



--
View this message in context: http://hercules390.996247.n3.nabble.com/Running-APL-360-on-OS-360-MVT-21-8F-MVT-for-APL-Version-2-00-available-tp39964p41234.html
Sent from the Hercules390 - General mailing list archive at Nabble.com.

[dhdurgee]

Post by Greg B
Do you have a specific POC for the Unicomp APL keyboards? I contacted them
and the respones was that they were "considering" another run of the APL
keyboard.

Can you read this:

http://support.pckeyboard.com/ticket.php?track=WQ3-7SV-XNEQ&e=dhdurgee%40verizon.net&Refresh=24735

In case you can't:

Case Tracking ID: WQ3-7SV-XNEQ

PC Keyboard Support Portal > PC Keyboard Help Desk > Your ticket
APL keyboards


Tracking ID: WQ3-7SV-XNEQ (Ticket number: 4677)
Ticket status: Resolved [Open ticket]
Created on: 2013-07-08 11:26:51
Updated: 2013-07-08 12:04:01
Last replier: Don Bowman
Category: Default
Replies: 1
Priority: Low





Date: 2013-07-08 11:26:51
Name: David H. Durgee
Email: dhdurgee (at) verizon (dot) net
Printer friendly version

Message:

Do you still offer an APL keyboard? I purchased one from you a while
ago and I know of some people that might be interested in purchasing
one, but I no longer see them listed on your web site. Are APL keyboards
still available?

Dave

Date: 2013-07-08 12:03:28
Name: Don Bowman
Printer friendly version

Message:

Dave, we have temporarily out of the APL keyboards. We hope to have them available in about 3 weeks. Please check our website for re-introduction of the APL keyboard in that timeframe.

Best regards,

Don Bowman
PC Keyboard
http://www.pckeyboard.com
Was this reply helpful? yes / no

[Greg B]

Thank you fro taking the time to respond. I was able to view your link
without problem. I'll be towards the front of the line in picking one of
these up.

Greg



--
View this message in context: http://hercules390.996247.n3.nabble.com/Running-APL-360-on-OS-360-MVT-21-8F-MVT-for-APL-Version-2-00-available-tp39964p41240.html
Sent from the Hercules390 - General mailing list archive at Nabble.com.

[William Gallant]

I have a few questions about STSC things.
Since you worked there, you might be able to assist me.
Rather than using posts here - could you please
contact me privately Bill?

wfg777inri-/***@public.gmane.org 


________________________________
From: wrljet <wrljet-***@public.gmane.org>
To: hercules-390-***@public.gmane.org
Sent: Monday, July 8, 2013 10:14 AM
Subject: [hercules-390] Re: APL keyboard stickers



 
I worked at STSC from 1981 to 1990, originally on VSAPL enhancements
(building NARS with Bob Smith), and later I was one of the developers of the from-scratch APL product we sold for Unix systems. I did the
386 protected mode port of that to run on MS-DOS.

Phelps Gates, author of the 16-bit APL*PLUS PC system, built the
front end editor for that. We thunked back and forth between
protected mode for the interpreter and real mode for his user
interface.

Anyway, to the point, here's a (not very good) picture of a set of
the original STSC APL*PLUS PC keyboard stickers.

http://www.wrljet.com/rennpics/apl-keyb-stickers.jpg

Bill




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

[[e-mail] [hercules-390]]

Something has changed with the HAO since the last Hercules build I used, so the
scripts for APL\360 no longer work.

Unfortunately I don't know how to tell what version I had before, other than it is
a sandhawk-master with files inside the zip dated 07/04/2013. When I run that
hercules it just announces itself as 4.00.

I've had that source laying around for some time. Just built it again a few days ago
and it does work correctly.

So I decided to try this with the latest 4.0 today from github and I'm getting some error messages I don't understand.

I'm guessing something has changed in the processing of the "hao cmd script"
but I don't have a clue what to change.

<<<
HHC02260I Script 1: begin processing file scripts/automatic_linux.rc
HHC01603I hao tgt IEE101A
HHC00077I The target was placed at index 0
HHC01603I hao cmd script scripts/jobnames
HHC00072E The command cmd given, but the command tgt was expected
HHC01603I hao tgt IKJ019I
HHC00077I The target was placed at index 0
HHC01603I hao cmd script scripts/sess
HHC00072E The command cmd given, but the command tgt was expected
HHC01603I hao tgt IEE334I
HHC00077I The target was placed at index 0
HHC01603I hao cmd script scripts/poweroff
HHC00072E The command cmd given, but the command tgt was expected
HHC01603I hao tgt APL APL HAS
HHC00077I The target was placed at index 0
HHC01603I hao cmd script scripts/client_linux
HHC00072E The command cmd given, but the command tgt was expected
Bill

[[e-mail] [hercules-390]]

Hi Bill


APL\360 will work with the Hercules version that comes with it _only_... It would be quite an effort to get it to work with any other version of Hercules -- and then: Why would one want to do this? It wouldn't bring the slightest advantage, neither in terms of functionality nor in terms of performance.


Cheers

JÃŒrgen

---In hercules-***@yahoogroups.com, <***@...> wrote :

Something has changed with the HAO since the last Hercules build I used, so the
scripts for APL\360 no longer work.

Unfortunately I don't know how to tell what version I had before, other than it is
a sandhawk-master with files inside the zip dated 07/04/2013. When I run that
hercules it just announces itself as 4.00.

I've had that source laying around for some time. Just built it again a few days ago
and it does work correctly.

So I decided to try this with the latest 4.0 today from github and I'm getting some error messages I don't understand.

I'm guessing something has changed in the processing of the "hao cmd script"
but I don't have a clue what to change.

<<<
HHC02260I Script 1: begin processing file scripts/automatic_linux.rc
HHC01603I hao tgt IEE101A
HHC00077I The target was placed at index 0
HHC01603I hao cmd script scripts/jobnames
HHC00072E The command cmd given, but the command tgt was expected
HHC01603I hao tgt IKJ019I
HHC00077I The target was placed at index 0
HHC01603I hao cmd script scripts/sess
HHC00072E The command cmd given, but the command tgt was expected
HHC01603I hao tgt IEE334I
HHC00077I The target was placed at index 0
HHC01603I hao cmd script scripts/poweroff
HHC00072E The command cmd given, but the command tgt was expected
HHC01603I hao tgt APL APL HAS
HHC00077I The target was placed at index 0
HHC01603I hao cmd script scripts/client_linux
HHC00072E The command cmd given, but the command tgt was expected
Bill

[[e-mail] [hercules-390]]

JÃŒrgen,

Why? For "hack value".

For what it's worth, I've applied your patches to several other Hercules versions along the way
(just for the heck of it) and it worked fine. I've even run it from a Raspberry Pi Zero.

Are your patches related to this HAO script problem and why it doesn't work with the
latest 4.0 trunk?

Bill

---In hercules-***@yahoogroups.com, <***@...> wrote :

Hi Bill


APL\360 will work with the Hercules version that comes with it _only_... It would be quite an effort to get it to work with any other version of Hercules -- and then: Why would one want to do this? It wouldn't bring the slightest advantage, neither in terms of functionality nor in terms of performance.


Cheers

JÃŒrgen

[[e-mail] [hercules-390]]

Hi Bill


good to read you succeeded on other Hercules versions .


My statement was about what the APL\360 package, which in fact is an appliance, supports. And that's just the Hercules version that comes with it. Of course I packaged the stuff with all source patches I created back then, and it's clear that applying these patches to other Hercules versions has a fair chance to work, as long as those Hercules versions don't differ too much from the base I used. But the point is, that I can't guarantee that this works, nor can I support this.


So, basically you've now reached the point where current Hercules versions differ too much from the old base for my patches to work. Sad to say: So, you'll have to rework them if you want to continue going down this road, be it for the heck of it or not .


Hint: First thing I would cross check would be the console telnet server.... I made many modifications there to get the APL\360 specific look and feel of the terminal to work and I'd really be surprised if that still worked with the new telnet handling that was introduced into Hyperion roughly a year ago.


Cheers
JÃŒrgen

---In hercules-***@yahoogroups.com, <***@...> wrote :


JÃŒrgen,

Why? For "hack value".

For what it's worth, I've applied your patches to several other Hercules versions along the way
(just for the heck of it) and it worked fine. I've even run it from a Raspberry Pi Zero.

Are your patches related to this HAO script problem and why it doesn't work with the
latest 4.0 trunk?

Bill

---In hercules-***@yahoogroups.com, <***@...> wrote :

Hi Bill


APL\360 will work with the Hercules version that comes with it _only_... It would be quite an effort to get it to work with any other version of Hercules -- and then: Why would one want to do this? It wouldn't bring the slightest advantage, neither in terms of functionality nor in terms of performance.


Cheers

JÃŒrgen

[[e-mail] [hercules-390]]

Post by ***@gmail.com [hercules-390]
So I decided to try this with the latest 4.0
today from github and I'm getting some
error messages I don't understand.
HHC01603I hao tgt IEE101A
HHC00077I The target was placed at index 0
HHC01603I hao cmd script scripts/jobnames
HHC00072E The command cmd given, but the command tgt was expected

I compared the latest Hyperion
hao_cmd() to 3.07 and can't see
any significant change:

C:\scratch>diff -w one.txt two.txt
16c16
< logmsg(HHCAO017E);
---

Post by ***@gmail.com [hercules-390]
WRMSG(HHC00071, "E", "command", HAO_MAXRULE);

24c24
< logmsg(HHCAO017E);
---

Post by ***@gmail.com [hercules-390]
WRMSG(HHC00072, "E", "cmd", "tgt");

32c32
< logmsg(HHCAO018E);
---

Post by ***@gmail.com [hercules-390]
WRMSG(HHC00073, "E", "command");

41c41
< logmsg(HHCA0026E);
---

Post by ***@gmail.com [hercules-390]
WRMSG(HHC00078, "E");

51c51
< logmsg(HHCAO019E, j);
---

Post by ***@gmail.com [hercules-390]
WRMSG(HHC00076, "E", "command", "target", j);

63c63
< logmsg(HHCAO015E, strerror(ENOMEM));
---

Post by ***@gmail.com [hercules-390]
WRMSG(HHC00075, "E", "strdup()", strerror(ENOMEM));

68c68
< logmsg(HHCAO020I, i);
---

Post by ***@gmail.com [hercules-390]
WRMSG(HHC00077, "I", "command", i);

C:\scratch>



Also nothing much in hao_tgt:

C:\scratch>diff -w three.txt four.txt
18c18
< logmsg(HHCAO010E);
---

Post by ***@gmail.com [hercules-390]
WRMSG(HHC00071, "E", "target", HAO_MAXRULE);

28c28
< logmsg(HHCAO011E);
---

Post by ***@gmail.com [hercules-390]
WRMSG(HHC00072, "E", "tgt", "cmd");

37c37
< logmsg(HHCAO012E);
---

Post by ***@gmail.com [hercules-390]
WRMSG(HHC00073, "E", "target");

47c47
< logmsg(HHCAO013E);
---

Post by ***@gmail.com [hercules-390]
WRMSG(HHC00074, "E", j);

53c53
< rc = regcomp(&ao_preg[i], arg, 0);
---

Post by ***@gmail.com [hercules-390]
rc = regcomp(&ao_preg[i], arg, REG_EXTENDED);

62c62
< logmsg(HHCAO014E, work);
---

Post by ***@gmail.com [hercules-390]
WRMSG(HHC00075, "E", "regcomp()", work);

73c73
< logmsg(HHCAO021E, i);
---

Post by ***@gmail.com [hercules-390]
WRMSG(HHC00076, "E", "target", "command", i);

86c86
< logmsg(HHCAO015E, strerror(ENOMEM));
---

Post by ***@gmail.com [hercules-390]
WRMSG(HHC00075, "E", "strdup()", strerror(ENOMEM));

91c91
< logmsg(HHCAO016I, i);
---

Post by ***@gmail.com [hercules-390]
WRMSG(HHC00077, "I", "target", i);

C:\scratch>




I was surprised to see this bit of code
in hao_tgt() though (in both versions):

/* find a free slot */
for(i = 0; ao_tgt[i] && i < HAO_MAXRULE; i++)

I expected to see a ";" at the end of that line
(as we see in hao_cmd()). But it should
work anyway.

Also, I have no idea how this code in
hao_tgt() 3.07 works:

/* check if not command is expected */
for(j = 0; j < HAO_MAXRULE; j++)
{
if(ao_tgt[j] && !ao_cmd[j])
{
release_lock(&ao_lock);
logmsg(HHCAO011E);
return;
}
}

Same code is in Hyperion, and will
produce the error message you saw:

/* check if not command is expected */
for(j = 0; j < HAO_MAXRULE; j++)
{
if(ao_tgt[j] && !ao_cmd[j])
{
release_lock(&ao_lock);
WRMSG(HHC00072, "E", "tgt", "cmd");
return;
}
}

But as I said, I expected that to equally
fail in 3.07, but 3.07 is somehow
working.

BFN. Paul.

[[e-mail] [hercules-390]]

Post by ***@yahoo.com.au [hercules-390]
Same code is in Hyperion, and will
if(ao_tgt[j] && !ao_cmd[j])

It seems to me that it is checking
that if there is any tgt without a
corresponding cmd, it will fail.
But the latest tgt will not have a
cmd yet!

However, now I get it.

It prevents another tgt command
coming through when there has
been no intervening "cmd".

So no idea what's going wrong.

BFN. Paul.

[[e-mail] [hercules-390]]

I just noticed, build that works includes a msg about the HAO thread starting:

HHC02260I Script 1: begin processing file scripts/automatic_linux.rc
HHC01603I hao tgt IEE101A
HHC00100I Thread id A9DEDB40, prio 0, name Hercules Automatic Operator started
HHC00077I The target was placed at index 0
HHC01603I hao cmd script scripts/jobnames
HHC00077I The command was placed at index 0

The new build that does not work doesn't have that msg.

There's a change to hao.c along the way:

From:

if(!logger_status())
{
haotid = 0;
return NULL;
}

WRMSG(HHC00100, "I", thread_id(), get_thread_priority(0), "Hercules Automatic Operator");

To:

if(!logger_isactive())
{
haotid = 0;
return NULL;
}

WRMSG(HHC00100, "I", thread_id(), get_thread_priority(0), "Hercules Automatic Operator");

[[e-mail] [hercules-390]]

Hi Bill


The Hercules version that comes with the APL\360 package is based on a Sandhawk snapshot from 11/30/2012, shortly before Sandhawk became Hyperion. As opposed to Spinhawk (the 3.xx quality release line maintained by Roger Bowler) the old Sandhawk already included much (not all) of the HAO functionality of the later Hyperion, in particular running HAO in an independent thread, which produces upon startup the message you observed.


Sandhawk's HAO functionality was a prerequisite for the automation framework I created for APL\360. So, you are observing here an incompatibility between Spinhawk and Hyperion/Sandhawk. My automation framework (neither in the APL\360 appliance, nor in the more recent TK4- MVS 3.8j appliance) never worked satisfactorily with Spinhawk, which was back in 2012 a main reason why I resorted to the somewhat risky Sandhawk development snapshot.


So, apparently, you are intermixing different problems here: HAO problems with APL\360 are clearly to be expected when running on a Spinhawk based (3.xx) version of Hercules. This can never have worked since day one of the APL\360 appliance until today.


So, the various builds you got to work must have been based on Hyperion snapshots. And my saying from yesterday referred to Hyperion, not to Spinhawk: To adapt the APL\360 appliance to work with a current Hyperion snapshot will most probably need a rework of the console/telnet related patches I created in 2012.


I don't see a need doing this (and consequently will not do it) because it doesn't bring a usable advantage to the appliance's functionality or performance. However, if you want to do it (for the heck of it or for whichever other reason) then by all means: Do it! However, it wouldn't be a bad idea to feed back your reworked versions of the patches and your build experiences to the Hercules community, for example in the files section of this forum .



Cheers
JÃŒrgen

---In hercules-***@yahoogroups.com, <***@...> wrote :


I just noticed, build that works includes a msg about the HAO thread starting:

HHC02260I Script 1: begin processing file scripts/automatic_linux.rc
HHC01603I hao tgt IEE101A
HHC00100I Thread id A9DEDB40, prio 0, name Hercules Automatic Operator started
HHC00077I The target was placed at index 0
HHC01603I hao cmd script scripts/jobnames
HHC00077I The command was placed at index 0

The new build that does not work doesn't have that msg.

There's a change to hao.c along the way:

From:

if(!logger_status())
{
haotid = 0;
return NULL;
}

WRMSG(HHC00100, "I", thread_id(), get_thread_priority(0), "Hercules Automatic Operator");

To:

if(!logger_isactive())
{
haotid = 0;
return NULL;
}

WRMSG(HHC00100, "I", thread_id(), get_thread_priority(0), "Hercules Automatic Operator");

[[e-mail] [hercules-390]]

Fish substantially re-wrote the console telnet code so re-working patches may be challenging




Dave



From: hercules-***@yahoogroups.com [mailto:hercules-***@yahoogroups.com]
Sent: 09 February 2017 08:52
To: hercules-***@yahoogroups.com
Subject: [hercules-390] Re: Running APL\360 on OS/360-MVT 21.8F: MVT for APL Version 2.00 available








Hi Bill



The Hercules version that comes with the APL\360 package is based on a Sandhawk snapshot from 11/30/2012, shortly before Sandhawk became Hyperion. As opposed to Spinhawk (the 3.xx quality release line maintained by Roger Bowler) the old Sandhawk already included much (not all) of the HAO functionality of the later Hyperion, in particular running HAO in an independent thread, which produces upon startup the message you observed.



Sandhawk's HAO functionality was a prerequisite for the automation framework I created for APL\360. So, you are observing here an incompatibility between Spinhawk and Hyperion/Sandhawk. My automation framework (neither in the APL\360 appliance, nor in the more recent TK4- MVS 3.8j appliance) never worked satisfactorily with Spinhawk, which was back in 2012 a main reason why I resorted to the somewhat risky Sandhawk development snapshot.



So, apparently, you are intermixing different problems here: HAO problems with APL\360 are clearly to be expected when running on a Spinhawk based (3.xx) version of Hercules. This can never have worked since day one of the APL\360 appliance until today.



So, the various builds you got to work must have been based on Hyperion snapshots. And my saying from yesterday referred to Hyperion, not to Spinhawk: To adapt the APL\360 appliance to work with a current Hyperion snapshot will most probably need a rework of the console/telnet related patches I created in 2012.



I don't see a need doing this (and consequently will not do it) because it doesn't bring a usable advantage to the appliance's functionality or performance. However, if you want to do it (for the heck of it or for whichever other reason) then by all means: Do it! However, it wouldn't be a bad idea to feed back your reworked versions of the patches and your build experiences to the Hercules community, for example in the files section of this forum <Loading Image...> .



Cheers

JÃŒrgen

---In hercules-***@yahoogroups.com <mailto:hercules-***@yahoogroups.com> , <***@... <mailto:***@...> > wrote :

I just noticed, build that works includes a msg about the HAO thread starting:

HHC02260I Script 1: begin processing file scripts/automatic_linux.rc
HHC01603I hao tgt IEE101A
HHC00100I Thread id A9DEDB40, prio 0, name Hercules Automatic Operator started
HHC00077I The target was placed at index 0
HHC01603I hao cmd script scripts/jobnames
HHC00077I The command was placed at index 0

The new build that does not work doesn't have that msg.

There's a change to hao.c along the way:

From:

if(!logger_status())
{
haotid = 0;
return NULL;
}

WRMSG(HHC00100, "I", thread_id(), get_thread_priority(0), "Hercules Automatic Operator");

To:

if(!logger_isactive())
{
haotid = 0;
return NULL;
}

WRMSG(HHC00100, "I", thread_id(), get_thread_priority(0), "Hercules Automatic Operator");

[[e-mail] [hercules-390]]

Exactly my saying, Dave


Cheers
JÃŒrgen

---In hercules-***@yahoogroups.com, <***@...> wrote :


Fish substantially re-wrote the console telnet code so re-working patches may be challenging


Dave

From: hercules-***@yahoogroups.com [mailto:hercules-***@yahoogroups.com]
Sent: 09 February 2017 08:52
To: hercules-***@yahoogroups.com
Subject: [hercules-390] Re: Running APL\360 on OS/360-MVT 21.8F: MVT for APL Version 2.00 available







Hi Bill

The Hercules version that comes with the APL\360 package is based on a Sandhawk snapshot from 11/30/2012, shortly before Sandhawk became Hyperion. As opposed to Spinhawk (the 3.xx quality release line maintained by Roger Bowler) the old Sandhawk already included much (not all) of the HAO functionality of the later Hyperion, in particular running HAO in an independent thread, which produces upon startup the message you observed.

Sandhawk's HAO functionality was a prerequisite for the automation framework I created for APL\360. So, you are observing here an incompatibility between Spinhawk and Hyperion/Sandhawk. My automation framework (neither in the APL\360 appliance, nor in the more recent TK4- MVS 3.8j appliance) never worked satisfactorily with Spinhawk, which was back in 2012 a main reason why I resorted to the somewhat risky Sandhawk development snapshot.

So, apparently, you are intermixing different problems here: HAO problems with APL\360 are clearly to be expected when running on a Spinhawk based (3.xx) version of Hercules. This can never have worked since day one of the APL\360 appliance until today.

So, the various builds you got to work must have been based on Hyperion snapshots. And my saying from yesterday referred to Hyperion, not to Spinhawk: To adapt the APL\360 appliance to work with a current Hyperion snapshot will most probably need a rework of the console/telnet related patches I created in 2012.

I don't see a need doing this (and consequently will not do it) because it doesn't bring a usable advantage to the appliance's functionality or performance. However, if you want to do it (for the heck of it or for whichever other reason) then by all means: Do it! However, it wouldn't be a bad idea to feed back your reworked versions of the patches and your build experiences to the Hercules community, for example in the files section of this forum .


Cheers

JÃŒrgen

---In hercules-***@yahoogroups.com mailto:hercules-***@yahoogroups.com, <***@... mailto:***@...> wrote :

I just noticed, build that works includes a msg about the HAO thread starting:

HHC02260I Script 1: begin processing file scripts/automatic_linux.rc
HHC01603I hao tgt IEE101A
HHC00100I Thread id A9DEDB40, prio 0, name Hercules Automatic Operator started
HHC00077I The target was placed at index 0
HHC01603I hao cmd script scripts/jobnames
HHC00077I The command was placed at index 0

The new build that does not work doesn't have that msg.

There's a change to hao.c along the way:

From:

if(!logger_status())
{
haotid = 0;
return NULL;
}

WRMSG(HHC00100, "I", thread_id(), get_thread_priority(0), "Hercules Automatic Operator");

To:

if(!logger_isactive())
{
haotid = 0;
return NULL;
}

WRMSG(HHC00100, "I", thread_id(), get_thread_priority(0), "Hercules Automatic Operator");

['\'Fish\' (David B. Trout)' [e-mail] [hercules-390]]

Post by ***@id.ethz.ch [hercules-390]

Post by ***@gmail.com [hercules-390]
Fish substantially re-wrote the console telnet code so
re-working patches may be challenging...

Exactly my saying, Dave

If you could explain in simple words what changes are needed I'd be happy to make them. The new telnet code is actually quite easy to work with once you get used to it. It was after all designed (not by me!) to be extensible and easily customizable while still ensuring adherence to the protocol.

[[e-mail] [hercules-390]]

Hi Fish


no problem at all: I didn't say that you should change anything at the new telnet code. I simply predicted Bill (and later on Dave articulated the same prediction) that adapting the APL\360 variant of console.c to the current Hyperion wouldn't be as trivial as his apparently successful earlier attempts. So, once again, no need to change anything for me...


Cheers
JÃŒrgen

Post by ***@id.ethz.ch [hercules-390]

Post by ***@gmail.com [hercules-390]
Fish substantially re-wrote the console telnet code so
re-working patches may be challenging...

Exactly my saying, Dave

If you could explain in simple words what changes are needed I'd be happy to make them. The new telnet code is actually quite easy to work with once you get used to it. It was after all designed (not by me!) to be extensible and easily customizable while still ensuring adherence to the protocol.

--
"Fish" (David B. Trout)
Software Development Laboratories
http://www.softdevlabs.com http://www.softdevlabs.com
mail: ***@... mailto:***@...

[[e-mail] [hercules-390]]

I found the reason the HAO for APL\360 doesn't work with the newer code.

I'm definitely not asking for any changes. I'm new to all this and don't yet understand
how it is intended to be used. But, that said, perhaps someone in-the-known might look over
what I've found, just in case it is a bug.

What I described here was done debugging with Visual Studio.

The HAO line "hao cmd script scripts/jobnames" gives the error msg:

"HHC00072E The command cmd given, but the command tgt was expected"

Because hao_initialize() is called for every command, wiping out ao_tgt[] from the previous command. Because of this code:

/* initialise hao */
if(!haotid && !hao_initialize())
WRMSG(HHC01404, "S");

Which does an early exit from the 'if' because haotid is NULL.

haotid is NULL because of code in hao_thread():

if(!logger_isactive())
{
haotid = 0;
return NULL;
}

Which returns NULL because the logger isn't running.

And, ultimately, the logger isn't running because of a change to impl.c which
turns off -d mode and skips starting the logger. Previous to this change,
logger_init() was always called.

<<<
Change: 11/24/2015
SHA-1: 79a0a17354d9f5ca9ce6032d3448aad3fca59ce2

* Fix impl.c to process arguments early so that flags are set correctly.

This implements daemon mode as it should be.

Still a number of problems (sigsevs), but it is unclear which are due
to this fix and what if due to my environment, so we stash this for now.


/* Set the daemon_mode flag indicating whether we running in
background/daemon mode or not (meaning both stdout/stderr
are redirected to a non-tty device). Note that this flag
needs to be set before logger_init gets called since the
logger_logfile_write function relies on its setting.
*/
if (!isatty(STDERR_FILENO) && !isatty(STDOUT_FILENO))
sysblk.daemon_mode = 1; /* Leave -d intact */

/* Initialize the logmsg pipe and associated logger thread.
This causes all subsequent logmsg's to be redirected to
the logger facility for handling by virtue of stdout/stderr
being redirected to the logger facility.
*/
if (!sysblk.daemon_mode) logger_init();
-Bill

[[e-mail] [hercules-390]]

Post by ***@gmail.com [hercules-390]
What I described here was done debugging with Visual Studio.

Thanks for your effort in debugging.

From what you describe, this bug
should be visible for everyone, all
they need to do is start Hercules,
and before even IPLing they just
need to type:

hao tgt xxx
hao cmd yyy

and they should see the problem,
is that correct?

If so, which versions of Hercules
should show the problem?

BFN. Paul.

[[e-mail] [hercules-390]]

Paul,

The APL\360 setup, as original, used the Hercules -d command line switch.
Not fully understanding how this all works, I also have used -d.

If -d is left off, then things "just work" and the system runs as expected,
with the exception of showing the PSW and command input lines.
It IPLs and processes the scripts for input.

(Then gets to the point of needing the APL patches for the terminal, etc. which is expected,
and is not the issue here)

But with -d, then the problem can be demonstrated as you suggest.

version.c(778) HHC01413I Hercules version 4.0.0.8707-g6fe56dc4-modified (4.0.0.8708)
version.c(790) HHC01414I (C) Copyright 1999-2016 by Roger Bowler, Jan Jaeger, and others
version.c(802) HHC01414I Commit 6fe56dc4e0422d8be24ba9bfe46f804ad109a4d3.
version.c(815) HHC01414I After commit: 3 added/modified/deleted files. 2 untracked files.
...
script.c(913) HHC02260I Script 1: begin processing file <stdin>
cmdtab.c(433) HHC90000D DBG: RC = 0
hao tgt xxx
cmdtab.c(679) HHC01603I hao tgt xxx
hao.c(276) HHC00077I The target was placed at index 0
cmdtab.c(433) HHC90000D DBG: RC = 0
hao cmd yyy
cmdtab.c(679) HHC01603I hao cmd yyy
hao.c(309) HHC00072E The command cmd given, but the command tgt was expected
cmdtab.c(433) HHC90000D DBG: RC = 0


Bill

Post by ***@gmail.com [hercules-390]
What I described here was done debugging with Visual Studio.

Thanks for your effort in debugging.

From what you describe, this bug
should be visible for everyone, all
they need to do is start Hercules,
and before even IPLing they just
need to type:

hao tgt xxx
hao cmd yyy

and they should see the problem,
is that correct?

If so, which versions of Hercules
should show the problem?

BFN. Paul.

[[e-mail] [hercules-390]]

Post by ***@gmail.com [hercules-390]
But with -d, then the problem can be
demonstrated as you suggest.
version.c(778) HHC01413I Hercules version 4.0.0.8707-g6fe56dc4-modified (4.0.0.8708)
cmdtab.c(679) HHC01603I hao tgt xxx
hao.c(276) HHC00077I The target was placed at index 0
cmdtab.c(679) HHC01603I hao cmd yyy
hao.c(309) HHC00072E The command cmd given, but the command tgt was expected

Hi Bill.

Thanks for documenting that. Can you
also confirm whether this problem only
exists on Hyperion or whether it also
occurs on Hercules 3.12 and 3.07?

Thanks. Paul.

[[e-mail] [hercules-390]]

Paul,

The biggest reason for the -d problem went in with this commit to Hyperion:

Change: 11/24/2015
SHA-1: 79a0a17354d9f5ca9ce6032d3448aad3fca59ce2

(Fish has fixed the whole thing on his fork.)

I've never tried it with 3.07 or 3.12, as the APL\360 mods were applied to a sandhawk.

Bill

Post by ***@gmail.com [hercules-390]
But with -d, then the problem can be
demonstrated as you suggest.
version.c(778) HHC01413I Hercules version 4.0.0.8707-g6fe56dc4-modified (4.0.0.8708)
cmdtab.c(679) HHC01603I hao tgt xxx
hao.c(276) HHC00077I The target was placed at index 0
cmdtab.c(679) HHC01603I hao cmd yyy
hao.c(309) HHC00072E The command cmd given, but the command tgt was expected

Hi Bill.

Thanks for documenting that. Can you
also confirm whether this problem only
exists on Hyperion or whether it also
occurs on Hercules 3.12 and 3.07?

Thanks. Paul.

[[e-mail] [hercules-390]]

Report it as a bug on GitHub




Dave



From: hercules-***@yahoogroups.com [mailto:hercules-***@yahoogroups.com]
Sent: 13 February 2017 20:44
To: hercules-***@yahoogroups.com
Subject: [hercules-390] Re: Running APL\360 on OS/360-MVT 21.8F: MVT for APL Version 2.00 available





Paul,

The biggest reason for the -d problem went in with this commit to Hyperion:

Change: 11/24/2015
SHA-1: 79a0a17354d9f5ca9ce6032d3448aad3fca59ce2

(Fish has fixed the whole thing on his fork.)

I've never tried it with 3.07 or 3.12, as the APL\360 mods were applied to a sandhawk.

Bill

Post by ***@gmail.com [hercules-390]
But with -d, then the problem can be
demonstrated as you suggest.
version.c(778) HHC01413I Hercules version 4.0.0.8707-g6fe56dc4-modified (4.0.0.8708)
cmdtab.c(679) HHC01603I hao tgt xxx
hao.c(276) HHC00077I The target was placed at index 0
cmdtab.c(679) HHC01603I hao cmd yyy
hao.c(309) HHC00072E The command cmd given, but the command tgt was expected

Hi Bill.

Thanks for documenting that. Can you
also confirm whether this problem only
exists on Hyperion or whether it also
occurs on Hercules 3.12 and 3.07?

Thanks. Paul.

[[e-mail] [hercules-390]]

Jurgen,
I just tried your wonderful APL 360 on my Ubuntu 14.04 machine. I then was successful in porting the Putty terminal to my Raspberry pi and recompiling the source with the patches so now I am at release .70. The
source .62 you provided would not compile under jessie. I kept getting AM_PATH_GTK not defined. But the .70 source works fine on the Pi. The patches did not need any modifications. The reason I am replying to this particular message is that I see you have it working on a raspberry pi zero. I was wondering if you could package that code like you do for the MVS appliance.


If you did not want to spend the time doing that could you publish the arm directory so I could just copy it into the APL version 2.0 version on my Raspberry Pi Zero?


One other small item is that if I make a key mistake I can't seem to correct it. I try backspace but when I overtype and press enter I get character error. Is there some other way to correct key mistakes other than retyping the whole line?


Again thanks so much for bringing this back to life .. I was reading through all these posts and I can see it was quite a journey.. but much appreciated ... APL was my first language I played with in college.


Sincerely,
Don Isenstadt

[[e-mail] [hercules-390]]

Post by ***@gmail.com [hercules-390]
Jurgen,
I just tried your wonderful APL 360 on my Ubuntu 14.04 machine. I then was successful
in porting the Putty terminal to my Raspberry pi and recompiling the source with the patches
so now I am at release .70. The source .62 you provided would not compile under jessie.
I kept getting AM_PATH_GTK not defined. But the .70 source works fine on the Pi.
The patches did not need any modifications.

Hi Don


good to see you are having fun with the resurrected APL\360 system! Thanks for the compliments .

Post by ***@gmail.com [hercules-390]
The reason I am replying to this particular message is that I see you have it working on a raspberry pi zero.

Well, I in fact don't have it working on a Raspberry Pi. The distribution currently runs on Windows, Linux and OS X systems, but not on ARM. The interest in the APL\360 distribution is rather small, there probably are no more than a few dozen users and I never heard a request for ARM support from them. So, if you read somewhere that it is running on ARM, then this probably got somehow confused. Maybe TK4- was meant? Or APL\360 on OS X? I've no idea...

Post by ***@gmail.com [hercules-390]
I was wondering if you could package that code like you do for the MVS appliance.
If you did not want to spend the time doing that could you publish the arm directory so I could just
copy it into the APL version 2.0 version on my Raspberry Pi Zero?

Of course, adding ARM support to the distro is as easy (or complicated -- depending on the point of view) than it was for TK4-. I'd be willing to put this on my list, but be aware that this can take forever: Until I'm out with the next TK4- update (which already is delayed for almost a year), I'll not even be looking into it to avoid getting side tracked. Sorry about that, but my very limited time budget, in addition to motivation problems I'm still facing since a skiing accident I had last spring, force me do to one step after the other with this hobby.

Post by ***@gmail.com [hercules-390]
One other small item is that if I make a key mistake I can't seem to correct it. I try backspace
but when I overtype and press enter I get character error. Is there some other way to correct
key mistakes other than retyping the whole line?

Well, that's an easy question, finally: APL\360 was written with typewriter terminals that print on real paper in mind, not screens as we have nowadays. To ease user interaction on that paper medium a thing named "visual fidelity" was invented, which allows backspacing and overtyping not as we expect it today on screens. Imagine having a sheet of paper, type something, then backspace and overtype... what happens on the paper? It overtypes, of course. Two things can happen: The overtyping creates either an invalid character, and so says APL then, or it creates a valid character, then it's taken for that. And the emulation I created for the PuTTY session shows exactly that same behavior. Try for example typing the input symbol (Shift L), then backspace and then the apostrophe (Shift K). What do you see on the PuTTY "paper" screen? The text input symbol which otherwise can't be found on the keyboard. Press Return and you'll see that APL prompts you for text input...


But visual fidelity goes even further: Type 5+2, followed by 5 times backspace, then 3x (x being the multiply symbol), then return. The system answers 21, which corresponds to the input line you are seeing on the "paper".


However, if you want to correct a typo, than you have to tell the system that you _do not_ want to overtype. This is done by backspacing and pressing Shift X, causing APL to skip to the next line, where you can continue typing.


See the MVT for APL User's Manual at page 13 for some background, and the APL\360 User's Manual for more details on visual fidelity.

Post by ***@gmail.com [hercules-390]
Again thanks so much for bringing this back to life .. I was reading through all these posts and
I can see it was quite a journey.. but much appreciated ... APL was my first language I played
with in college.

You're welcome!


APL was also one of my first computer languages and I did all the computations for my mathematics diploma thesis in APL .


Cheers
JÃŒrgen

[Mike Stramba [e-mail] [hercules-390]]

I've just installed the mvt4apl-2.00 system on a Win 7 pro laptop.

Everything is working but ...

How do I *delete* a line from a program/function definition ?

According to the APL\360 primer
http://bitsavers.org/pdf/ibm/apl/C20-1702-0_APL_360_Primer_1969.pdf (
pg 46) :

1) Enter the line number enclosed in square brackets, then press ATTN

I've tried [xx] CTR-A, and [xx] CTR-C, then exiting the function
with "del" (shift G).

When I "open" the function with "del" again, the "deleted" lines are
still there.

Mike

Post by ***@gmail.com [hercules-390]

Post by ***@gmail.com [hercules-390]
Jurgen,
I just tried your wonderful APL 360 on my Ubuntu 14.04 machine. I then

was successful

Post by ***@gmail.com [hercules-390]
in porting the Putty terminal to my Raspberry pi and recompiling the

source with the patches

Post by ***@gmail.com [hercules-390]
so now I am at release .70. The source .62 you provided would not compile

under jessie.

Post by ***@gmail.com [hercules-390]
I kept getting AM_PATH_GTK not defined. But the .70 source works fine on

the Pi.

Post by ***@gmail.com [hercules-390]
The patches did not need any modifications.

Hi Don
good to see you are having fun with the resurrected APL\360 system! Thanks
for the compliments .

Post by ***@gmail.com [hercules-390]
The reason I am replying to this particular message is that I see you

have it working on a raspberry pi zero.
Well, I in fact don't have it working on a Raspberry Pi. The distribution
currently runs on Windows, Linux and OS X systems, but not on ARM. The
interest in the APL\360 distribution is rather small, there probably are no
more than a few dozen users and I never heard a request for ARM support from
them. So, if you read somewhere that it is running on ARM, then this
probably got somehow confused. Maybe TK4- was meant? Or APL\360 on OS X?
I've no idea...

Post by ***@gmail.com [hercules-390]
I was wondering if you could package that code like you do for the MVS

appliance.

Post by ***@gmail.com [hercules-390]
If you did not want to spend the time doing that could you publish the

arm directory so I could just

Post by ***@gmail.com [hercules-390]
copy it into the APL version 2.0 version on my Raspberry Pi Zero?

Of course, adding ARM support to the distro is as easy (or complicated --
depending on the point of view) than it was for TK4-. I'd be willing to put
this on my list, but be aware that this can take forever: Until I'm out with
the next TK4- update (which already is delayed for almost a year), I'll not
even be looking into it to avoid getting side tracked. Sorry about that, but
my very limited time budget, in addition to motivation problems I'm still
facing since a skiing accident I had last spring, force me do to one step
after the other with this hobby.

Post by ***@gmail.com [hercules-390]
One other small item is that if I make a key mistake I can't seem to

correct it. I try backspace

Post by ***@gmail.com [hercules-390]
but when I overtype and press enter I get character error. Is there some

other way to correct

Post by ***@gmail.com [hercules-390]
key mistakes other than retyping the whole line?

Well, that's an easy question, finally: APL\360 was written with typewriter
terminals that print on real paper in mind, not screens as we have nowadays.
To ease user interaction on that paper medium a thing named "visual
fidelity" was invented, which allows backspacing and overtyping not as we
expect it today on screens. Imagine having a sheet of paper, type something,
then backspace and overtype... what happens on the paper? It overtypes, of
course. Two things can happen: The overtyping creates either an invalid
character, and so says APL then, or it creates a valid character, then it's
taken for that. And the emulation I created for the PuTTY session shows
exactly that same behavior. Try for example typing the input symbol (Shift
L), then backspace and then the apostrophe (Shift K). What do you see on the
PuTTY "paper" screen? The text input symbol which otherwise can't be found
on the keyboard. Press Return and you'll see that APL prompts you for text
input...
But visual fidelity goes even further: Type 5+2, followed by 5 times
backspace, then 3x (x being the multiply symbol), then return. The system
answers 21, which corresponds to the input line you are seeing on the
"paper".
However, if you want to correct a typo, than you have to tell the system
that you _do not_ want to overtype. This is done by backspacing and pressing
Shift X, causing APL to skip to the next line, where you can continue
typing.
See the MVT for APL User's Manual at page 13 for some background, and the
APL\360 User's Manual for more details on visual fidelity.

Post by ***@gmail.com [hercules-390]
Again thanks so much for bringing this back to life .. I was reading

through all these posts and

Post by ***@gmail.com [hercules-390]
I can see it was quite a journey.. but much appreciated ... APL was my

first language I played

Post by ***@gmail.com [hercules-390]
with in college.

You're welcome!
APL was also one of my first computer languages and I did all the
computations for my mathematics diploma thesis in APL .
Cheers
JÃŒrgen

[Jeremy Nicoll [e-mail] [hercules-390]]

Post by Mike Stramba ***@gmail.com [hercules-390]
1) Enter the line number enclosed in square brackets, then press ATTN
I've tried [xx] CTR-A, and [xx] CTR-C, then exiting the function
with "del" (shift G).
When I "open" the function with "del" again, the "deleted" lines are
still there.

You need to press whichever key you've mapped to ATTN (a specific
key on a 3270 terminal) in your 3270 emulator.

[Tony Harminc [e-mail] [hercules-390]]

Post by Jeremy Nicoll ***@letterboxes.org [hercules-390]
You need to press whichever key you've mapped to ATTN (a specific
key on a 3270 terminal) in your 3270 emulator.

That's a good generic answer to people asking about 3270 emulators,
but here it just causes confusion because there is no 3270 in the
picture. APL\360 does not have any 3270 support.

Tony H.

[[e-mail] [hercules-390]]

Hi Mike


in the given context, by ATTN in fact LINEFEED is meant, which on the original 1052-7 typewriter terminal doesn't exist. This key is instead simulated by Shift-X, as described in the MVT for APL Users manual on page 13. See also the APL\360 primer on page 11 for the use of ATTN in line editing. There is also mentioned, that LINEFEED, INDEX and ATTN have the same function in APL\360, i.e. whichever of them is found on a given terminal, can be substituted for ATTN.


So, to your specific question, deleting line xx in a program requires the following sequence of keystrokes:


[xx] Shift-X Return



without the blanks, which I put in for readability only.


Cheers
JÃŒrgen

---In hercules-***@yahoogroups.com, <***@...> wrote :


I've just installed the mvt4apl-2.00 system on a Win 7 pro laptop.

Everything is working but ...

How do I *delete* a line from a program/function definition ?

According to the APL\360 primer
http://bitsavers.org/pdf/ibm/apl/C20-1702-0_APL_360_Primer_1969.pdf http://bitsavers.org/pdf/ibm/apl/C20-1702-0_APL_360_Primer_1969.pdf (
pg 46) :

1) Enter the line number enclosed in square brackets, then press ATTN

I've tried [xx] CTR-A, and [xx] CTR-C, then exiting the function
with "del" (shift G).

When I "open" the function with "del" again, the "deleted" lines are
still there.

Mike

Post by ***@gmail.com [hercules-390]

Post by ***@gmail.com [hercules-390]
Jurgen,
I just tried your wonderful APL 360 on my Ubuntu 14.04 machine. I then

was successful

Post by ***@gmail.com [hercules-390]
in porting the Putty terminal to my Raspberry pi and recompiling the

source with the patches

Post by ***@gmail.com [hercules-390]
so now I am at release .70. The source .62 you provided would not compile

under jessie.

Post by ***@gmail.com [hercules-390]
I kept getting AM_PATH_GTK not defined. But the .70 source works fine on

the Pi.

Post by ***@gmail.com [hercules-390]
The patches did not need any modifications.

Hi Don
good to see you are having fun with the resurrected APL\360 system! Thanks
for the compliments .

Post by ***@gmail.com [hercules-390]
The reason I am replying to this particular message is that I see you

have it working on a raspberry pi zero.
Well, I in fact don't have it working on a Raspberry Pi. The distribution
currently runs on Windows, Linux and OS X systems, but not on ARM. The
interest in the APL\360 distribution is rather small, there probably are no
more than a few dozen users and I never heard a request for ARM support from
them. So, if you read somewhere that it is running on ARM, then this
probably got somehow confused. Maybe TK4- was meant? Or APL\360 on OS X?
I've no idea...

Post by ***@gmail.com [hercules-390]
I was wondering if you could package that code like you do for the MVS

appliance.

Post by ***@gmail.com [hercules-390]
If you did not want to spend the time doing that could you publish the

arm directory so I could just

Post by ***@gmail.com [hercules-390]
copy it into the APL version 2.0 version on my Raspberry Pi Zero?

Of course, adding ARM support to the distro is as easy (or complicated --
depending on the point of view) than it was for TK4-. I'd be willing to put
this on my list, but be aware that this can take forever: Until I'm out with
the next TK4- update (which already is delayed for almost a year), I'll not
even be looking into it to avoid getting side tracked. Sorry about that, but
my very limited time budget, in addition to motivation problems I'm still
facing since a skiing accident I had last spring, force me do to one step
after the other with this hobby.

Post by ***@gmail.com [hercules-390]
One other small item is that if I make a key mistake I can't seem to

correct it. I try backspace

Post by ***@gmail.com [hercules-390]
but when I overtype and press enter I get character error. Is there some

other way to correct

Post by ***@gmail.com [hercules-390]
key mistakes other than retyping the whole line?

Well, that's an easy question, finally: APL\360 was written with typewriter
terminals that print on real paper in mind, not screens as we have nowadays.
To ease user interaction on that paper medium a thing named "visual
fidelity" was invented, which allows backspacing and overtyping not as we
expect it today on screens. Imagine having a sheet of paper, type something,
then backspace and overtype... what happens on the paper? It overtypes, of
course. Two things can happen: The overtyping creates either an invalid
character, and so says APL then, or it creates a valid character, then it's
taken for that. And the emulation I created for the PuTTY session shows
exactly that same behavior. Try for example typing the input symbol (Shift
L), then backspace and then the apostrophe (Shift K). What do you see on the
PuTTY "paper" screen? The text input symbol which otherwise can't be found
on the keyboard. Press Return and you'll see that APL prompts you for text
input...
But visual fidelity goes even further: Type 5+2, followed by 5 times
backspace, then 3x (x being the multiply symbol), then return. The system
answers 21, which corresponds to the input line you are seeing on the
"paper".
However, if you want to correct a typo, than you have to tell the system
that you _do not_ want to overtype. This is done by backspacing and pressing
Shift X, causing APL to skip to the next line, where you can continue
typing.
See the MVT for APL User's Manual at page 13 for some background, and the
APL\360 User's Manual for more details on visual fidelity.

Post by ***@gmail.com [hercules-390]
Again thanks so much for bringing this back to life .. I was reading

through all these posts and

Post by ***@gmail.com [hercules-390]
I can see it was quite a journey.. but much appreciated ... APL was my

first language I played

Post by ***@gmail.com [hercules-390]
with in college.

You're welcome!
APL was also one of my first computer languages and I did all the
computations for my mathematics diploma thesis in APL .
Cheers
JÃŒrgen

[Mike Stramba [e-mail] [hercules-390]]

JÃŒrgen,

Thanks very much !

Mike

Post by ***@id.ethz.ch [hercules-390]
Hi Mike
in the given context, by ATTN in fact LINEFEED is meant, which on the
original 1052-7 typewriter terminal doesn't exist. This key is instead
simulated by Shift-X, as described in the MVT for APL Users manual on page
13. See also the APL\360 primer on page 11 for the use of ATTN in line
editing. There is also mentioned, that LINEFEED, INDEX and ATTN have the
same function in APL\360, i.e. whichever of them is found on a given
terminal, can be substituted for ATTN.
So, to your specific question, deleting line xx in a program requires the
[xx] Shift-X Return
without the blanks, which I put in for readability only.
Cheers
JÃŒrgen
I've just installed the mvt4apl-2.00 system on a Win 7 pro laptop.
Everything is working but ...
How do I *delete* a line from a program/function definition ?
According to the APL\360 primer
http://bitsavers.org/pdf/ibm/apl/C20-1702-0_APL_360_Primer_1969.pdf
http://bitsavers.org/pdf/ibm/apl/C20-1702-0_APL_360_Primer_1969.pdf (
1) Enter the line number enclosed in square brackets, then press ATTN
I've tried [xx] CTR-A, and [xx] CTR-C, then exiting the function
with "del" (shift G).
When I "open" the function with "del" again, the "deleted" lines are
still there.
Mike

Post by ***@gmail.com [hercules-390]

Post by ***@gmail.com [hercules-390]
Jurgen,
I just tried your wonderful APL 360 on my Ubuntu 14.04 machine. I then

was successful

Post by ***@gmail.com [hercules-390]
in porting the Putty terminal to my Raspberry pi and recompiling the

source with the patches

Post by ***@gmail.com [hercules-390]
so now I am at release .70. The source .62 you provided would not

compile

Post by ***@gmail.com [hercules-390]
under jessie.

Post by ***@gmail.com [hercules-390]
I kept getting AM_PATH_GTK not defined. But the .70 source works fine

on

Post by ***@gmail.com [hercules-390]
the Pi.

Post by ***@gmail.com [hercules-390]
The patches did not need any modifications.

Hi Don
good to see you are having fun with the resurrected APL\360 system!

Thanks

Post by ***@gmail.com [hercules-390]
for the compliments .

Post by ***@gmail.com [hercules-390]
The reason I am replying to this particular message is that I see you

have it working on a raspberry pi zero.
Well, I in fact don't have it working on a Raspberry Pi. The

distribution

Post by ***@gmail.com [hercules-390]
currently runs on Windows, Linux and OS X systems, but not on ARM. The
interest in the APL\360 distribution is rather small, there probably are

no

Post by ***@gmail.com [hercules-390]
more than a few dozen users and I never heard a request for ARM support

from

Post by ***@gmail.com [hercules-390]
them. So, if you read somewhere that it is running on ARM, then this
probably got somehow confused. Maybe TK4- was meant? Or APL\360 on OS X?
I've no idea...

Post by ***@gmail.com [hercules-390]
I was wondering if you could package that code like you do for the MVS

appliance.

Post by ***@gmail.com [hercules-390]
If you did not want to spend the time doing that could you publish the

arm directory so I could just

Post by ***@gmail.com [hercules-390]
copy it into the APL version 2.0 version on my Raspberry Pi Zero?

Of course, adding ARM support to the distro is as easy (or complicated

--

Post by ***@gmail.com [hercules-390]
depending on the point of view) than it was for TK4-. I'd be willing to

put

Post by ***@gmail.com [hercules-390]
this on my list, but be aware that this can take forever: Until I'm out

with

Post by ***@gmail.com [hercules-390]
the next TK4- update (which already is delayed for almost a year), I'll

not

Post by ***@gmail.com [hercules-390]
even be looking into it to avoid getting side tracked. Sorry about that,

but

Post by ***@gmail.com [hercules-390]
my very limited time budget, in addition to motivation problems I'm

still

Post by ***@gmail.com [hercules-390]
facing since a skiing accident I had last spring, force me do to one

step

Post by ***@gmail.com [hercules-390]
after the other with this hobby.

Post by ***@gmail.com [hercules-390]
One other small item is that if I make a key mistake I can't seem to

correct it. I try backspace

Post by ***@gmail.com [hercules-390]
but when I overtype and press enter I get character error. Is there

some

Post by ***@gmail.com [hercules-390]
other way to correct

Post by ***@gmail.com [hercules-390]
key mistakes other than retyping the whole line?

Well, that's an easy question, finally: APL\360 was written with

typewriter

Post by ***@gmail.com [hercules-390]
terminals that print on real paper in mind, not screens as we have

nowadays.

Post by ***@gmail.com [hercules-390]
To ease user interaction on that paper medium a thing named "visual
fidelity" was invented, which allows backspacing and overtyping not as

we

Post by ***@gmail.com [hercules-390]
expect it today on screens. Imagine having a sheet of paper, type

something,

Post by ***@gmail.com [hercules-390]
then backspace and overtype... what happens on the paper? It overtypes,

of

Post by ***@gmail.com [hercules-390]
course. Two things can happen: The overtyping creates either an invalid
character, and so says APL then, or it creates a valid character, then

it's

Post by ***@gmail.com [hercules-390]
taken for that. And the emulation I created for the PuTTY session shows
exactly that same behavior. Try for example typing the input symbol

(Shift

Post by ***@gmail.com [hercules-390]
L), then backspace and then the apostrophe (Shift K). What do you see on

the

Post by ***@gmail.com [hercules-390]
PuTTY "paper" screen? The text input symbol which otherwise can't be

found

Post by ***@gmail.com [hercules-390]
on the keyboard. Press Return and you'll see that APL prompts you for

text

Post by ***@gmail.com [hercules-390]
input...
But visual fidelity goes even further: Type 5+2, followed by 5 times
backspace, then 3x (x being the multiply symbol), then return. The

system

Post by ***@gmail.com [hercules-390]
answers 21, which corresponds to the input line you are seeing on the
"paper".
However, if you want to correct a typo, than you have to tell the system
that you _do not_ want to overtype. This is done by backspacing and

pressing

Post by ***@gmail.com [hercules-390]
Shift X, causing APL to skip to the next line, where you can continue
typing.
See the MVT for APL User's Manual at page 13 for some background, and

the

Post by ***@gmail.com [hercules-390]
APL\360 User's Manual for more details on visual fidelity.

Post by ***@gmail.com [hercules-390]
Again thanks so much for bringing this back to life .. I was reading

through all these posts and

Post by ***@gmail.com [hercules-390]
I can see it was quite a journey.. but much appreciated ... APL was my

first language I played

Post by ***@gmail.com [hercules-390]
with in college.

You're welcome!
APL was also one of my first computer languages and I did all the
computations for my mathematics diploma thesis in APL .
Cheers
JÃŒrgen

[[e-mail] [hercules-390]]

Post by ***@id.ethz.ch [hercules-390]

Post by ***@gmail.com [hercules-390]
I was wondering if you could package that code like you do for the MVS appliance.
If you did not want to spend the time doing that could you publish the arm directory so I could just
copy it into the APL version 2.0 version on my Raspberry Pi Zero?

Of course, adding ARM support to the distro is as easy (or complicated -- depending on the point of view)
than it was for TK4-. I'd be willing to put this on my list, but be aware that this can take forever: Until I'm out
with the next TK4- update (which already is delayed for almost a year), I'll not even be looking into it to avoid
getting side tracked. Sorry about that, but my very limited time budget, in addition to motivation problems
I'm still facing since a skiing accident I had last spring, force me do to one step after the other with
this hobby.

Hi Don


you're lucky: I got side tracked just after I wrote that post. Things started working in my head and I could bring this to an end only by doing the job. So, here it is: Please find the ARM support on http://wotho.ethz.ch/mvt4apl-2.00 http://wotho.ethz.ch/mvt4apl-2.00/. As usual, there is an "update" zip that can be applied to existing systems and two "current system" zips (normal and large) for new installations.


Please note: On older ARM platforms insufficient compute power might make it difficult to perform the initial assembly of the APL\360 source. Should this be the case on your system, simply perform the initial installation elsewhere and then transfer the DASDs together with file <mvt4apl folder>/aplinst/status to the ARM system.


Have fun!


Cheers
JÃŒrgen

['\'Fish\' (David B. Trout)' [e-mail] [hercules-390]]

Post by ***@gmail.com [hercules-390]
I found the reason the HAO for APL\360 doesn't work with
the newer code.
I'm definitely not asking for any changes. I'm new to all
this and don't yet understand how it is intended to be used.
But, that said, perhaps someone in-the-know might look over
what I've found, just in case it is a bug.

<snip>

I have looked over your analysis and it is definitely a bug.

While I have no idea how the current team(?) of Hyperion developers responsible for maintaining the OFFICIAL Hyperion development repository intend to address it, I myself have recently completed a series of commits to my UNOFFICIAL Fish-Git Hyperion fork that fixes the problem:

https://github.com/Fish-Git/hyperion