Re: TXTLIB and Stack Question
On Tue, Feb 25, 2020 at 02:16 PM, gdblodgett wrote:
The 257 byte length of the ARGVARGS field will indeed hold 32 arguments (8x32=256) plus 1 byte for a fence/termination character.
Thanks Gary hope you had a good coffee! I am trying the fix now - it is?ARGSTRNG that I need to clear (dyslexia). You are right that ARGVARS is big enough - but ARGSTRNG?needs to hold spaces ... and the program name - and with eplist could be longer?? Anyway, a theoretical problem, I will raise an issue for another day!
|
Re: TXTLIB and Stack Question
Hi Adrian,
OK, I've had enough coffee and am awake now.? LOL
Yes, the MVI & MVC combination is pretty much the norm for
clearing/initializing memory.? I've seen other ways, but I'll not
cloud the issue.? Clearing/initializing that field is a good idea.
With C, the argc/argv combination gives you the actual value(s)
from the command line.? In IBM assembler the PLIST gives you the
address of the location of each of the 8 byte values.?
An example in the program is on line 55.? In the comment area
"RESLIB LIST GCCLIB ( NOTYPE" would be typed on the command line.?
Line 290-295 shows how it will appear after being parsed.? The
PLIST will contain the address of each portion of the command line
plus and 8 byte "fence"/termination field of all x'FF' (high
values).
Eight (8) is the magic number because Command names, file names,
file types and the like in CMS are all 8 characters or less.
The 257 byte length of the ARGVARGS field will indeed hold 32
arguments (8x32=256) plus 1 byte for a fence/termination
character.
Gary
On 2/25/20 6:57 AM, adriansutherland67
wrote:
toggle quoted message
Show quoted text
OK - So I understand the issue now with PLIST, basically I would
need to add
MVI? ?0(R3),C' '
after line 253. This makes sure that the proper end of the token
is found even is some preexisting junk is there in the target
ARGVARGS.
But I have no chance of seeing if the same
problem exists in EPLIST let alone fixing it (for a start I could
not test it!).
Therefore the safest thing to do is instead clear this
ARGVARGS DS CL257
down to zeros (or spaces?) first. The trouble is my S/370 is crap
(nonexistent!), is this the most efficient/elegant way?
MVI?
ARGVARGS,X'0'? ? ? ? ? ? ? ? ?* Zero start
MVC?
ARGVARGS+1(256),ARGVARGS? ? ? * Propagate to the rest?
Anyway I will see it it works!
|
Re: TXTLIB and Stack Question
Hi Adrian,
Assembler can be cryptic at times but so can C.
The DS in the MAINSTK statement means Define Storage.? The 32000F states that variable 32000 "F"s in size.? With "F" meaning a full word (4 bytes) aligned on a full word boundary.? So it's 32000 x 4 = 128000 bytes long, aligned on a full word boundary.?
The meaning for "ARGVARGS DS? ? CL257" is again, define storage, this time though is a different notation. The "C" means character (1 byte), the "L" means length. So, it is 257 bytes long with no alignment enforced.?
I've just crawled out of bed, but I will try and take a peek at it after I get some coffee.
Gary?
Sent from my T-Mobile 4G LTE Device
toggle quoted message
Show quoted text
-------- Original message -------- From: adriansutherland67 <adrian@...> Date: 2/25/20 4:50 AM (GMT-05:00) Subject: [h390-vm] TXTLIB and Stack Question
Hello I am chasing down a bug in CMSLIB whereby (TBC) the last argument to main() is not properly null terminated if it is 8 chars long and a previous C command had a longer program name (note that the program name is arg 0). I note that the bit that does this is all assembler :-( Anyway, I unexpectedly found this was true between resident (DMXREX) and nonresident versions (BREXX) - one interferes with the other.?? Can anyone help with the following questions - I appreciate they will be in a doco but I also know that some of you will just know! I also appreciate that CMS is a simple single user / program system - multi-process was not the order of the day ... 1/ If two programs use the same TXTLIB (e.g. but I guess not only, if one is resident and the other isn't) is the TXTLIB loaded in memory once only - the two programs share the TXTLIB and any global variables. Is this right? 2/ In the C startup library I see
* ---------------------------------------------------------------------
* Here begins the GCC stack:? local variables of the GCC routines.
* ---------------------------------------------------------------------
MAINSTK? DS? ? 32000F
a/ Is this telling me that the stack starts at 32000 hex (about 200k) and therefore the stack grows upwards, or is it hex 32000F (about 3mb) which seems a weird address ... b/ This means that all C programs stacks start at the same address and will inevitably trash each others stacks? Has anyone any suggestions about how CMS Assembler programs get round this - I remember something about? CMS subset? Does that have different standard addresses? And what about programs loaded high? 3/ Similarly
ARGVARGS DS? ? CL257? ? ? ? ? arguments to main program
Tells me that this buffer for main() arguments is in a non-reentrant global variable - right? It is also too short for 32 args mentioned elsewhere in the code, but anyway! And The bug ...The file is here? And line 215 seems fine (terminating) - but it does not check that the arg is 8 chars or fewer. From testing the symptom, it is about the program name being shorter (from the last run) and somehow the calculation of the start of the parameters is out, and it is picking up a character from the previous run at the end of the params. So can anyone help with line 150? I think this should point to char 8 (or 9?) from the START of the program name, is it pointing to the end of the trimmed / stripped program name instead?? Does anyone have the format of the EPLIST or whatever? And - I wish this bit was written in C!!!! I am quite scared about changing it :-) Adrian
|
Re: TXTLIB and Stack Question
OK - So I understand the issue now with PLIST, basically I would need to add
MVI? ?0(R3),C' '
after line 253. This makes sure that the proper end of the token is found even is some preexisting junk is there in the target ARGVARGS. But I have no chance of seeing if the same problem exists in EPLIST let alone fixing it (for a start I could not test it!). Therefore the safest thing to do is instead clear this
ARGVARGS DS CL257
down to zeros (or spaces?) first. The trouble is my S/370 is crap (nonexistent!), is this the most efficient/elegant way?
MVI? ARGVARGS,X'0'? ? ? ? ? ? ? ? ?* Zero start
MVC? ARGVARGS+1(256),ARGVARGS? ? ? * Propagate to the rest?
Anyway I will see it it works!
|
TXTLIB and Stack Question
Hello I am chasing down a bug in CMSLIB whereby (TBC) the last argument to main() is not properly null terminated if it is 8 chars long and a previous C command had a longer program name (note that the program name is arg 0). I note that the bit that does this is all assembler :-( Anyway, I unexpectedly found this was true between resident (DMXREX) and nonresident versions (BREXX) - one interferes with the other.?? Can anyone help with the following questions - I appreciate they will be in a doco but I also know that some of you will just know! I also appreciate that CMS is a simple single user / program system - multi-process was not the order of the day ... 1/ If two programs use the same TXTLIB (e.g. but I guess not only, if one is resident and the other isn't) is the TXTLIB loaded in memory once only - the two programs share the TXTLIB and any global variables. Is this right? 2/ In the C startup library I see
* ---------------------------------------------------------------------
* Here begins the GCC stack:? local variables of the GCC routines.
* ---------------------------------------------------------------------
MAINSTK? DS? ? 32000F
a/ Is this telling me that the stack starts at 32000 hex (about 200k) and therefore the stack grows upwards, or is it hex 32000F (about 3mb) which seems a weird address ... b/ This means that all C programs stacks start at the same address and will inevitably trash each others stacks? Has anyone any suggestions about how CMS Assembler programs get round this - I remember something about? CMS subset? Does that have different standard addresses? And what about programs loaded high? 3/ Similarly
ARGVARGS DS? ? CL257? ? ? ? ? arguments to main program
Tells me that this buffer for main() arguments is in a non-reentrant global variable - right? It is also too short for 32 args mentioned elsewhere in the code, but anyway! And The bug ...The file is here? And line 215 seems fine (terminating) - but it does not check that the arg is 8 chars or fewer. From testing the symptom, it is about the program name being shorter (from the last run) and somehow the calculation of the start of the parameters is out, and it is picking up a character from the previous run at the end of the params. So can anyone help with line 150? I think this should point to char 8 (or 9?) from the START of the program name, is it pointing to the end of the trimmed / stripped program name instead?? Does anyone have the format of the EPLIST or whatever? And - I wish this bit was written in C!!!! I am quite scared about changing it :-) Adrian
|
Re: CTCE on the same host with unique ports
Please note that my? of the? is available for anyone who wishes to beta test my CTCE v2 corrections and improvements (as well as some older changes). The code is not finalized yet, some problems are known to exist, but as a successful CTCE connection was made yesterday (a VTAM non-MPC CTCA link to a? Hercules system), I'd appreciate testing feedback. The new CTCE support for the CTC DEBUG ON <devnum> command may be helpful.
When this spinhawk CTCE v2 work has been sufficiently tested, I will make a pull request for it, but cannot guarantee that these will be actually carried out.?
Feedback welcome !
Cheers,
Peter?
|
Re: CTCE on the same host with unique ports
On 2/24/20 12:44 AM, Peter Jansen via Groups.Io wrote: Drew, the upcoming backport of my CTCE v2 corrections and improvements will have an improved output from the DEVLIST <devnum> command which I thus hope will address this. The existing command CTC DEBUG … will then also support CTCE devices to assist debugging this even better. If you point me at your next CTCE Spinhawk version when it's public (github?), I'll beta test.? :-) -- Drew Derbyshire "A hobbit will get you through times of no bagels better than bagels will get you through times of no hobbit." -- The Grey-eyed Elf
|
Re: CTCE on the same host with unique ports
Drew, the upcoming backport of my CTCE v2 corrections and improvements will have an improved output from the DEVLIST <devnum> command which I thus hope will address this. The existing command CTC DEBUG … will then also support CTCE devices to assist debugging this even better.
Cheers,
Peter
|
Re: CTCE on the same host with unique ports
Drew, yes, you're right, it appears that keyword "3088" in the current spinhawk CTCE is optional. Thanks for making me aware of this.
Cheers,
Peter
|
Re: CTCE on the same host with unique ports
BTW, please print the full status of the CTCE; this is not
useful when debugging half open links:
0:0E44 3088 .:....=127.0.0.1:2216
open????????????????????????????????????????????????????????????????????????????
0:0E45 3088 .:....=127.0.0.1:2218 open
--
Drew Derbyshire
"It may sound absurd . . . but don't be naive
Even Heroes have the right to bleed
I may be disturbed . . . but won't you concede
Even Heroes have the right to dream
It's not easy to be me"
-- Five for Fighting, "Superman (It's Not Easy)"
|
Re: CTCE on the same host with unique ports
On 2/23/20 8:25 AM, Peter Jansen via
Groups.Io wrote:
Drew,
My earlier reply has not yet been approved by the moderators,
which is good because it was wrong.
No, the configuration statement for all 3088 type devices on
spinhawk still requires the keyword 3088 following the device
number (CCUU address), i.e. :
veronica/veronica.conf: 08C0???? 3088 CTCE??? 2216 localhost 2316
It's not needed in my copy, which was pulled from Github January
6.?
veronica.conf:08C0???? CTCE??? 2216 localhost 2316
veronica.conf:08C1???? CTCE??? 2218 localhost 2318
log/veronica.log:22:28:14 HHCCT063I 08C0 CTCE: Awaiting inbound
connection :2217 <- 127.0.0.1:2316
log/veronica.log:22:28:14 HHCCT063I 08C1 CTCE: Awaiting inbound
connection :2219 <- 127.0.0.1:2318
log/veronica.log:22:28:19 HHCCT070I 08C0 CTCE: Accepted inbound
connection :2217 <- 127.0.0.1:2316 (bufsize=61592,12)
log/veronica.log:22:28:19 HHCCT070I 08C1 CTCE: Accepted inbound
connection :2219 <- 127.0.0.1:2318 (bufsize=61592,12)
viola-network-io.conf:0e44???? CTCE??? 2316 localhost 2216
viola-network-io.conf:0e45???? CTCE??? 2318 localhost 2218
log/viola.log:22:28:02 HHCCT063I 0E44 CTCE: Awaiting inbound
connection :2317 <- 127.0.0.1:2216
log/viola.log:22:28:02 HHCCT063I 0E45 CTCE: Awaiting inbound
connection :2319 <- 127.0.0.1:2218
log/viola.log:22:28:19 HHCCT054I 0E44 CTCE: Started outbound
connection :2316 -> 127.0.0.1:2217
log/viola.log:22:28:19 HHCCT072S 0E44 CTCE: Not all sockets
connected: send=62, receive=-1
log/viola.log:22:28:19 HHCCT054I 0E45 CTCE: Started outbound
connection :2318 -> 127.0.0.1:2219
log/viola.log:22:28:19 HHCCT072S 0E45 CTCE: Not all sockets
connected: send=64, receive=-1
log/viola.log:22:29:39 HHCCT072S 0E44 CTCE: Not all sockets
connected: send=62, receive=-1
log/viola.log:22:29:39 HHCCT072S 0E44 CTCE: Not all sockets
connected: send=62, receive=-1
log/viola.log:22:29:41 HHCCT072S 0E44 CTCE: Not all sockets
connected: send=62, receive=-1
--
Drew Derbyshire
Vidi, vici, veni.
|
Re: CTCE on the same host with unique ports
Drew,
My earlier reply has not yet been approved by the moderators, which is good because it was wrong.
No, the configuration statement for all 3088 type devices on spinhawk still requires the keyword 3088 following the device number (CCUU address), i.e. :
veronica/veronica.conf: 08C0???? 3088 CTCE??? 2216 localhost 2316
and so on.? In? this *3088" keyword is no longer allowed.?
By the way, SDL-hyperion already has my latest CTCE v2 corrections and improvements, which I'm in the process of backporting to spinhawk as well.
Cheers,
Peter?
|
Re: CTCE on the same host with unique ports
Yes Drew, this is a correct configuration, not only on spinhawk, but also on? where my newest CTCE v2 is already committed (and which still supports that format as well).
By the way, I intend to backport the same CTCE v2 corrections and improvements on spinhawk as well. I have just started the testing of that backport.
Cheers,
Peter
|
CTCE on the same host with unique ports
On spinhawk, is this the correct configuration to connect two
systems on the same host??
The example uses unique IP addresses and same port numbers.
veronica/veronica.conf: 08C0???? CTCE??? 2216 localhost 2316
veronica/veronica.conf: 08C1???? CTCE??? 2218 localhost 2318
viola/viola.conf: 0e44???? CTCE??? 2316 localhost 2216
viola/viola.conf: 0e45???? CTCE??? 2318 localhost 2218
Thanks in advance,
-ahd-
--
Drew Derbyshire
I'm back in the saddle again . . .
|
great work, I’ll be sure to check it over the weekend!
toggle quoted message
Show quoted text
On 22 Feb 2020, at 16:01, adriansutherland67 < adrian@...> wrote:
Automatic build done ... added to latest docker image.
I'll try and actually do some debugging now!
|
Automatic build done ... added to latest docker image.
I'll try and actually do some debugging now!
|
yes, that is fine with me, I’ll start on the testsuite and the errors that remain when the gcc runtime gets better
toggle quoted message
Show quoted text
On 21 Feb 2020, at 22:32, adriansutherland67 < adrian@...> wrote:
On Fri, Feb 21, 2020 at 06:25 PM, rvjansen@... wrote:
let’s use the issue system to avoid doing duplicate work
I think you can assign people to issues.? I would like to concentrate on reentrancy, residency, and gcclib issues if that works for you?
|
On Fri, Feb 21, 2020 at 06:25 PM, rvjansen@... wrote:
let’s use the issue system to avoid doing duplicate work
I think you can assign people to issues.? I would like to concentrate on reentrancy, residency, and gcclib issues if that works for you?
|
On Fri, Feb 21, 2020 at 06:25 PM, rvjansen@... wrote:
can herccontrol address a non-console session?
No ... I disconnect and logon the user to the console as needed. However if you are using a real mainframe that won't work :-(
|
On 21 Feb 2020, at 18:06, adriansutherland67 < adrian@...> wrote:
On Tue, Feb 18, 2020 at 03:44 PM, rvjansen@... wrote:
I checked in the current source, will add some of the VM modules also. I started with the .corig sources and checked them in as.c, and then checked in the current .c modules, so we can track them with git diff. As a result, some of the files are empty now (and are not part of the build procedure - hmm).
Added some missing files (just headers I think - also separated the .horig files following your approach) and made all the files lower case (sorry!!).
yes, forgot about the .h files, noticed that just now when trying to compile on z/VM.
lower case, fine. I prefer that too. Added some very rough instructions.txt for release management. Basically make a feature/f000n (or hotfix/h0001) and work there until you are happy with it and then we both can stage it to a release.
yes, that would also be good for the wiki.
BREXX built and ran manually (good!) - so I am just going to automate that (feature f0001). I have the template from GCCLIB so should not take long. Then we will have each check-in building and running whatever tests we have automatically on GITHUB servers. And it can feed the upstream VM/370 image build. Quick turnaround for bugs (well assuming we can work out how to fix the bugs!)
let’s use the issue system to avoid doing duplicate work. I’ll assign to myself if I start on some issue (assuming github can do that, did not look yet) I can't (well wont!!) use any s3270 scripts myself - happy with driving the console via my herccontrol thingy. And it is bedded-in for the github builds.?
can herccontrol address a non-console session?
best regards,
搁别苍é. Cheers
Adrian
|
Peter Jansen
