On 19 Mar 2013, at 15:07, "Mark Pizzolato - Info Comm" <Mark at infocomm.com> wrote:
Numerous changes over the last few days. Please pull the latest from github before proceeding.
When I compile on Dave s system using Sun C ( 5.12), I needed to change the line endings to LF from CR-LF.
If dos2unix took a list of filenames to convert in-place then we d merely do:
$ dos2unix makefile *.txt *.c *.h */*.h */*.c
Since dos2unix doesn t work like I d hope, we can get around this with unzip:
$ unzip aa master.zip
$ mkdir temp
$ cd temp
$ unzip ../master.zip
$ cp simh-master/VAX/*.bin simh-master/VAX/*.exe ../simh-master/VAX/
$ cd ../simh-master
$ /opt/csw/bin/gmake vax GCC=/opt/solarisstudio12.3/bin/CC
I will update you on whether that works once I work around
bash-3.2# ifconfig vnic0 inet 10.10.2.1 netmask 255.255.0.0
ifconfig: could not create address:Object not found
Hitting an issue when using SunCC from Solaris Studio now:
bash-3.2$ /opt/csw/bin/gmake vax GCC=/opt/solarisstudio12.3/bin/CC
lib paths are: /lib /usr/lib
using libm: /lib/libm.so
using librt: /lib/librt.so
using libpthread: /lib/libpthread.so /usr/include/pthread.h
using libdl: /lib/libdl.so /usr/include/dlfcn.h
using libpcap: /usr/include/pcap.h
***
*** vax Simulator being built with:
*** - compiler optimizations and no debugging support. Sun C 5.12.
*** - dynamic networking support using Solaris provided libpcap components.
***
/opt/solarisstudio12.3/bin/CC -U__STRICT_ANSI__ -O2 -I . -D_GNU_SOURCE -D_LARGEFILE_SOURCE -DUSE_READER_THREAD -DSIM_ASYNCH_IO -DHAVE_DLOPEN=so sim_BuildROMs.c -o BIN/BuildROMs
"sim_BuildROMs.c", line 42: Warning: String literal converted to char* in initialization.
"sim_BuildROMs.c", line 42: Warning: String literal converted to char* in initialization.
"sim_BuildROMs.c", line 42: Warning: String literal converted to char* in initialization.
"sim_BuildROMs..c", line 43: Warning: String literal converted to char* in initialization.
"sim_BuildROMs.c", line 43: Warning: String literal converted to char* in initialization..
"sim_BuildROMs.c", line 43: Warning: String literal converted to char* in initialization.
"sim_BuildROMs.c", line 44: Warning: String literal converted to char* in initialization.
"sim_BuildROMs.c", line 44: Warning: String literal converted to char* in initialization.
"sim_BuildROMs.c", line 44: Warning: String literal converted to char* in initialization.
"sim_BuildROMs.c", line 45: Warning: String literal converted to char* in initialization.
"sim_BuildROMs.c", line 45: Warning: String literal converted to char* in initialization.
"sim_BuildROMs.c", line 45: Warning: String literal converted to char* in initialization.
"sim_BuildROMs.c", line 46: Warning: String literal converted to char* in initialization.
"sim_BuildROMs.c", line 46: Warning: String literal converted to char* in initialization.
"sim_BuildROMs.c", line 46: Warning: String literal converted to char* in initialization.
"sim_BuildROMs.c", line 107: Error: Cannot assign void* to char*.
"sim_BuildROMs..c", line 119: Error: Cannot assign void* to unsigned char*.
"sim_BuildROMs.c", line 158: Error: Cannot assign void* to unsigned char*.
"sim_BuildROMs.c", line 169: Error: Cannot assign const char* to char*.
"sim_BuildROMs.c", line 245: Error: Cannot assign void* to unsigned char*.
5 Error(s) and 15 Warning(s) detected.
gmake: *** [BIN/BuildROMs] Error 2
Numerous changes over the last few days. Please pull the latest from github before proceeding.
When I compile on Dave s system using Sun C ( 5.12), I needed to change the line endings to LF from CR-LF.
If dos2unix took a list of filenames to convert in-place then we d merely do:
$ dos2unix makefile *.txt *.c *.h */*.h */*.c
Since dos2unix doesn t work like I d hope, we can get around this with unzip:
$ unzip aa master.zip
$ mkdir temp
$ cd temp
$ unzip ../master.zip
$ cp simh-master/VAX/*.bin simh-master/VAX/*.exe ../simh-master/VAX/
$ cd ../simh-master
$ /opt/csw/bin/gmake vax GCC=/opt/solarisstudio12.3/bin/CC
Hitting an issue when using SunCC from Solaris Studio now:
bash-3.2$ /opt/csw/bin/gmake vax GCC=/opt/solarisstudio12.3/bin/CC
lib paths are: /lib /usr/lib
using libm: /lib/libm.so
using librt: /lib/librt.so
using libpthread: /lib/libpthread.so /usr/include/pthread.h
using libdl: /lib/libdl.so /usr/include/dlfcn.h
using libpcap: /usr/include/pcap.h
***
*** vax Simulator being built with:
*** - compiler optimizations and no debugging support. Sun C 5.12.
*** - dynamic networking support using Solaris provided libpcap components.
***
/opt/solarisstudio12.3/bin/CC -U__STRICT_ANSI__ -O2 -I . -D_GNU_SOURCE -D_LARGEFILE_SOURCE -DUSE_READER_THREAD -DSIM_ASYNCH_IO -DHAVE_DLOPEN=so sim_BuildROMs.c -o BIN/BuildROMs
"sim_BuildROMs.c", line 42: Warning: String literal converted to char* in initialization.
"sim_BuildROMs.c", line 42: Warning: String literal converted to char* in initialization.
"sim_BuildROMs.c", line 42: Warning: String literal converted to char* in initialization.
"sim_BuildROMs.c", line 43: Warning: String literal converted to char* in initialization.
"sim_BuildROMs.c", line 43: Warning: String literal converted to char* in initialization.
"sim_BuildROMs.c", line 43: Warning: String literal converted to char* in initialization.
"sim_BuildROMs.c", line 44: Warning: String literal converted to char* in initialization.
"sim_BuildROMs.c", line 44: Warning: String literal converted to char* in initialization.
"sim_BuildROMs.c", line 44: Warning: String literal converted to char* in initialization.
"sim_BuildROMs.c", line 45: Warning: String literal converted to char* in initialization.
"sim_BuildROMs.c", line 45: Warning: String literal converted to char* in initialization.
"sim_BuildROMs.c", line 45: Warning: String literal converted to char* in initialization.
"sim_BuildROMs.c", line 46: Warning: String literal converted to char* in initialization.
"sim_BuildROMs.c", line 46: Warning: String literal converted to char* in initialization.
"sim_BuildROMs.c", line 46: Warning: String literal converted to char* in initialization.
"sim_BuildROMs.c", line 107: Error: Cannot assign void* to char*.
"sim_BuildROMs.c", line 119: Error: Cannot assign void* to unsigned char*.
"sim_BuildROMs.c", line 158: Error: Cannot assign void* to unsigned char*.
"sim_BuildROMs.c", line 169: Error: Cannot assign const char* to char*.
"sim_BuildROMs.c", line 245: Error: Cannot assign void* to unsigned char*.
5 Error(s) and 15 Warning(s) detected.
gmake: *** [BIN/BuildROMs] Error 2
On 18 Mar 2013, at 17:25, "Cory Smelosky" <b4 at gewt.net> wrote:
On 18 Mar 2013, at 17:18, "Gregg Levine" <gregg.drwho8 at gmail.com> wrote:
On Mon, Mar 18, 2013 at 5:10 PM, Cory Smelosky <b4 at gewt.net> wrote:
On 17 Mar 2013, at 00:25, "Cory Smelosky" <b4 at gewt.net> wrote:
On 17 Mar 2013, at 00:23, "Dave McGuire" <mcguire at neurotica.com> wrote:
On 03/17/2013 12:06 AM, Cory Smelosky wrote:
Indeed it is. I hope OpenSXCE gets off the ground in a meaningful
way.
It runs great. I talk with the guy (Martin) every now and then.
I believe he's the kind of guy who is motivated by people actually
using his stuff. I say RUN it. (it runs great!) And tell him about
it. Thank him for it. Then he'll continue to make it happen.
I did that a little while ago and never got a response. I believe I
was polite and I know I definitely thanked him. I was certainly not
insulting him. I would run it if I could get zones to work at all.
That's the limiting factor for running OpenSXCE. Along with my
inability to get more than the one drive working to help with
staging. ;)
Remember he has only sporadic network access.
Ahhh. Right. I keep forgetting about that.
I've gotten OpenSXCE installed and I have managed to get zones to work. It took a little bit of effort and a lot of time but I have done it.
Now to get everything set up so I can bring my SIMH instances back. ;)
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
Hello!
Good to know. Also the cards arrived today. It took me a while to
remember what was in the box, and, as it happens the clew was where
they ran over here from. Thank you!
Very good to know! I knew the problem could be solved with persistence. ;)
Welcome! Apologies about the delay in getting them out.
Dave please stop staring at that car. It's not planning on moving
until the end of the week. Also the Cybermen need 32 Gigabytes more
for their project.
Gigabytes or Gibibytes? ;)
-----
Gregg C Levine gregg.drwho8 at gmail.com
"This signature fought the Time Wars, time and again."
Hitting an issue when using SunCC from Solaris Studio now:
bash-3.2$ /opt/csw/bin/gmake vax GCC=/opt/solarisstudio12.3/bin/CC
lib paths are: /lib /usr/lib
using libm: /lib/libm.so
using librt: /lib/librt.so
using libpthread: /lib/libpthread.so /usr/include/pthread.h
using libdl: /lib/libdl.so /usr/include/dlfcn.h
using libpcap: /usr/include/pcap.h
***
*** vax Simulator being built with:
*** - compiler optimizations and no debugging support. Sun C 5.12.
*** - dynamic networking support using Solaris provided libpcap components.
***
/opt/solarisstudio12.3/bin/CC -U__STRICT_ANSI__ -O2 -I . -D_GNU_SOURCE -D_LARGEFILE_SOURCE -DUSE_READER_THREAD -DSIM_ASYNCH_IO -DHAVE_DLOPEN=so sim_BuildROMs.c -o BIN/BuildROMs
"sim_BuildROMs.c", line 42: Warning: String literal converted to char* in initialization.
"sim_BuildROMs.c", line 42: Warning: String literal converted to char* in initialization.
"sim_BuildROMs.c", line 42: Warning: String literal converted to char* in initialization.
"sim_BuildROMs.c", line 43: Warning: String literal converted to char* in initialization.
"sim_BuildROMs.c", line 43: Warning: String literal converted to char* in initialization.
"sim_BuildROMs.c", line 43: Warning: String literal converted to char* in initialization.
"sim_BuildROMs.c", line 44: Warning: String literal converted to char* in initialization.
"sim_BuildROMs.c", line 44: Warning: String literal converted to char* in initialization.
"sim_BuildROMs.c", line 44: Warning: String literal converted to char* in initialization.
"sim_BuildROMs.c", line 45: Warning: String literal converted to char* in initialization.
"sim_BuildROMs.c", line 45: Warning: String literal converted to char* in initialization.
"sim_BuildROMs.c", line 45: Warning: String literal converted to char* in initialization.
"sim_BuildROMs.c", line 46: Warning: String literal converted to char* in initialization.
"sim_BuildROMs.c", line 46: Warning: String literal converted to char* in initialization.
"sim_BuildROMs.c", line 46: Warning: String literal converted to char* in initialization.
"sim_BuildROMs.c", line 107: Error: Cannot assign void* to char*.
"sim_BuildROMs.c", line 119: Error: Cannot assign void* to unsigned char*.
"sim_BuildROMs.c", line 158: Error: Cannot assign void* to unsigned char*.
"sim_BuildROMs.c", line 169: Error: Cannot assign const char* to char*.
"sim_BuildROMs.c", line 245: Error: Cannot assign void* to unsigned char*.
5 Error(s) and 15 Warning(s) detected.
gmake: *** [BIN/BuildROMs] Error 2
output of CC -flags: http://pastebin.com/mRc9t6Y1
On 18 Mar 2013, at 17:18, "Gregg Levine" <gregg.drwho8 at gmail.com> wrote:
On Mon, Mar 18, 2013 at 5:10 PM, Cory Smelosky <b4 at gewt.net> wrote:
On 17 Mar 2013, at 00:25, "Cory Smelosky" <b4 at gewt.net> wrote:
On 17 Mar 2013, at 00:23, "Dave McGuire" <mcguire at neurotica.com> wrote:
On 03/17/2013 12:06 AM, Cory Smelosky wrote:
Indeed it is. I hope OpenSXCE gets off the ground in a meaningful
way.
It runs great. I talk with the guy (Martin) every now and then.
I believe he's the kind of guy who is motivated by people actually
using his stuff. I say RUN it. (it runs great!) And tell him about
it. Thank him for it. Then he'll continue to make it happen.
I did that a little while ago and never got a response. I believe I
was polite and I know I definitely thanked him. I was certainly not
insulting him. I would run it if I could get zones to work at all.
That's the limiting factor for running OpenSXCE. Along with my
inability to get more than the one drive working to help with
staging. ;)
Remember he has only sporadic network access.
Ahhh. Right. I keep forgetting about that.
I've gotten OpenSXCE installed and I have managed to get zones to work. It took a little bit of effort and a lot of time but I have done it.
Now to get everything set up so I can bring my SIMH instances back. ;)
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
Hello!
Good to know. Also the cards arrived today. It took me a while to
remember what was in the box, and, as it happens the clew was where
they ran over here from. Thank you!
Very good to know! I knew the problem could be solved with persistence. ;)
Welcome! Apologies about the delay in getting them out.
Dave please stop staring at that car. It's not planning on moving
until the end of the week. Also the Cybermen need 32 Gigabytes more
for their project.
Gigabytes or Gibibytes? ;)
-----
Gregg C Levine gregg.drwho8 at gmail.com
"This signature fought the Time Wars, time and again."
On Mon, Mar 18, 2013 at 5:10 PM, Cory Smelosky <b4 at gewt.net> wrote:
On 17 Mar 2013, at 00:25, "Cory Smelosky" <b4 at gewt.net> wrote:
On 17 Mar 2013, at 00:23, "Dave McGuire" <mcguire at neurotica.com> wrote:
On 03/17/2013 12:06 AM, Cory Smelosky wrote:
Indeed it is. I hope OpenSXCE gets off the ground in a meaningful
way.
It runs great. I talk with the guy (Martin) every now and then.
I believe he's the kind of guy who is motivated by people actually
using his stuff. I say RUN it. (it runs great!) And tell him about
it. Thank him for it. Then he'll continue to make it happen.
I did that a little while ago and never got a response. I believe I
was polite and I know I definitely thanked him. I was certainly not
insulting him. I would run it if I could get zones to work at all.
That's the limiting factor for running OpenSXCE. Along with my
inability to get more than the one drive working to help with
staging. ;)
Remember he has only sporadic network access.
Ahhh. Right. I keep forgetting about that.
I've gotten OpenSXCE installed and I have managed to get zones to work. It took a little bit of effort and a lot of time but I have done it.
Now to get everything set up so I can bring my SIMH instances back. ;)
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
Hello!
Good to know. Also the cards arrived today. It took me a while to
remember what was in the box, and, as it happens the clew was where
they ran over here from. Thank you!
Dave please stop staring at that car. It's not planning on moving
until the end of the week. Also the Cybermen need 32 Gigabytes more
for their project.
-----
Gregg C Levine gregg.drwho8 at gmail.com
"This signature fought the Time Wars, time and again."
On 17 Mar 2013, at 00:25, "Cory Smelosky" <b4 at gewt.net> wrote:
On 17 Mar 2013, at 00:23, "Dave McGuire" <mcguire at neurotica.com> wrote:
On 03/17/2013 12:06 AM, Cory Smelosky wrote:
Indeed it is. I hope OpenSXCE gets off the ground in a meaningful
way.
It runs great. I talk with the guy (Martin) every now and then.
I believe he's the kind of guy who is motivated by people actually
using his stuff. I say RUN it. (it runs great!) And tell him about
it. Thank him for it. Then he'll continue to make it happen.
I did that a little while ago and never got a response. I believe I
was polite and I know I definitely thanked him. I was certainly not
insulting him. I would run it if I could get zones to work at all.
That's the limiting factor for running OpenSXCE. Along with my
inability to get more than the one drive working to help with
staging. ;)
Remember he has only sporadic network access.
Ahhh. Right. I keep forgetting about that.
I've gotten OpenSXCE installed and I have managed to get zones to work. It took a little bit of effort and a lot of time but I have done it.
Now to get everything set up so I can bring my SIMH instances back. ;)
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
On 2013-03-17 22:10, Michael Holmes wrote:
since web isn't locked down as tight I was looking for a solution
that I could use from my web browser at work.
Any suggestions ?
Shellinabox from https://code.google.com/p/shellinabox/
It is running in the wild on eg. http://www.telehack.com and
http://olduse.net/
re,
/Jacob
I'm going to be installing WASD on my alpha server and looking to see if anyone knows of any freeware or shareware solution that would allow me to remote into (like telnet) my AS via web (80/443)?
The firewalls at work do not allow us to telnet or SSH out (unless the address has been approved through a long bureaucratic process), so I can't look at my home system from work during lunch.
since web isn't locked down as tight I was looking for a solution that I could use from my web browser at work.
Any suggestions ?
On 2013-03-17 14:48, Mark Benson wrote:
On 17 Mar 2013, at 12:49, Johnny Billquist wrote:
PIP LB:[1,6]SYSSCAN.TMP;1/RM
Noted for future reference :)
:-)
That happened at reboot - maybe something to do with the system accounting (not that I have much of an idea what that is)?
By the way:
.err 334
000334 (-36): %I/O-F-IE.SQC, file ID, sequence number check
Just in case you want to know. :-)
Fascinating... I assume that translates to something like "the file system says it's there but it's not there!" :)
More or less. It's a case of you have a directory entry, but there is no actual file. In RSX (as in VMS) that is entirely possible to have. So, the file system says the file don't exist, but you have a "dangling pointer". :-)
I'll assume you know how Unix systems work, and I'll make an explanation based on that.
Directory entries in RSX are the same as hard links in Unix. Absolutely the same in all aspects. A directory entry in RSX is just the file name, and the corresponding file id it refers to. A file id in RSX is the same as an inode number in Unix.
The biggest difference is that RSX do not do reference counting of files. Thus, you can have several links to a file, and yet delete the file without deleting the directory entries. At that point, the directory entries will point to a file that don't exist.
Since file IDs are reused, RSX have a second trick to avoid an old directory entry from accidentally refer to a new file. Every time a file id is reused, a second number is incremented, and the full file id consists of both the id number as such, and the sequence number.
Thus, if you have a directory entry which points to a file, but the file it referred to have been deleted, and the file id have been reused, you'll get the file sequence error message.
As a side note, you can also refer to, and operate on files in RSX by just using the file ids directly. You do not need to go through the directory and get a mapping from name to id, as you do in Unix. The basic I/O operations actually take the file id as their argument.
System accounting is essentially the keeping track of how much CPU time each user consumes, how many pages printed, how many I/Os done, and so on...
Oh, so it's a system audit process, similar to VMS. I got it.
More or less, yes.
And yes, the error have everything to do with accounting. The accounting subsystem keeps a snapshot on a temporary file while running. The idea is that in case of a system crash, you'll have a fairly accurate snapshot to pick up after reboot. But occasionally, you'll get unlucky, and the file has been deleted, but the directory entry is still there.
Oh. That's a quaintly analogue system. "It may be able to provide a snapshot... if it works... and the file hasn't disappeared."
:-)
Don't complain. You could run a VFY at every reboot, if you wanted better integrity (Unix fsck anyone?). However, the file system is robust enough that it's not normally needed.
SYSSCAN is just a program that works in a way that can cause it to trip itself up. It could be improved to solve this. I guess that noone thought it worth the effort.
I suspect the reason is I don't actually know how to cleanly shutdown RSX-11M+. I vaguely remember something about a SHUTUP command?
Yes, there is a SHUTUP program. Just type RUN SHUTUP.
However, apart from the accounting system, I'm not aware of anything else that gets particularly upset.
A VFY once a year or so to check and fix up possible disk inconsistencies are a good idea, but that's about it.
And the SYSSCAN issue is easily solved manually if needed.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
That is the explanation. You have to:
RUN $SHUTUP
To shut down cleanly. Else you will find consistently the SYSSCAN.TMP problem you describe. The magic spell Johnny wrote about will fix the problem in case you can't shutdown properly.
Jordi Guillaumes i Pons
Barcelona - Catalunya - Europa
El 17/03/2013, a les 14:48, Mark Benson <md.benson at gmail.com> va escriure:
suspect the reason is I don't actually know how to cleanly shutdown RSX-11M+. I vaguely remember something about a SHUTUP command?
