Keyboard Shortcuts
ctrl + shift + ? :
Show all keyboard shortcuts
ctrl + g :
Navigate to a group
ctrl + shift + f :
Find
ctrl + / :
Quick actions
esc to dismiss
Likes
- H390-DOSVS
- Messages
Search
|
Re: NESTED SUBROUTINES
Not only that, but DOS/VS r 34 didnt?follow the OS calling conventions.? Joe On Wed, Oct 12, 2022 at 10:11 AM Richard Cornwell <rich@...> wrote: Hi Tom, |
||
|
Re: NESTED SUBROUTINES
ok, maybe a little progress.? Knowing that standard calls do not work, as you state, means that I have to do my own. Ok, now for some testing..... Thank You very much. cheers /tom c On Wed, Oct 12, 2022 at 10:11 AM Richard Cornwell <rich@...> wrote: Hi Tom, |
||
|
Re: NESTED SUBROUTINES
Hi Tom,
toggle quoted message
Show quoted text
You are going to have to implement your own routines. Perhaps check out how Algol or PL/1 handle subroutine calls. But standard call routines do not support re-entrant calls. Rich
|
||
|
Re: NESTED SUBROUTINES
Richard, Thank you for the info.? I need to figure out how to implement your suggestion.? I found in the documentation on SAVE an option ?????????? SAVE? (14,12),,xxxxxxx where xxxx is a ds 18f area to save the regs.? I am trying to figure out if the change will work on DOS/VS rel 34. Cheers /tom c On Wed, Oct 12, 2022 at 9:59 AM Richard Cornwell <rich@...> wrote: Hi Tom, |
||
|
Re: NESTED SUBROUTINES
Hi Tom,
Typically 360/370 subroutine calls are done with a what is called a save area. This is 18 words allocated within the subroutine. On entry the registers are saved into the previous routines save area. Then the base register is set up and the save pointer is pointed to the current save area. On exit the registers are restore, this will include the previous save area. This means that if you call a subroutine again it will wipe out the previous calls information. To do this properly you will either need to allocate a bunch of memory to save all the registers in and advance the save pointer for each call. The other option is to allocate and free save areas at each call. Basically you will need to implement some sort of stack to handle function calls if you want true recursive calls. Rich |
||
|
Re: NESTED SUBROUTINES
Fish,
Thank you for comments.? You confirmed what I thought was the issue. Looking through the fish-macros, I noticed you have a modified save macro.? Should I be using that version? I have written a test program that nest three levels.? Level one and Level two work then it fails.? I am using the SAVE , CALL, and RETURN macros. I think it is a matter of getting the saving of R13 correctly and use of the correct save area for each subroutine. Thank you for your help. Cheers /tom c |
||
|
EchoParm
Fran Hensler wrote a routine, EchoParm, which allows for the use of
EXEC PARM= . The program compiles but will not run via DOS/VS rel 34.? It is stated in the JCL: Restriction:? This program will work in DOS/VS R34 only if????? * *?????????????? modifications to $JOBCTLE are made to support???? * *?????????????? the PARM= field on the EXEC statement.??????? What I am trying to locate is the modifications to $JOBCTLE. for DOSVS rel 34.? I have emailed the author and waiting for response. If anyone has any information about the above changes to $JOBCTLE for DOSVS rel 34, it would be appreciated. Thank You /tom c |
||
|
Re: NESTED SUBROUTINES
[...]
main -> sub1 -> sub2 -> sub1 -> mainHow do you have your subroutine linkage designed? Simple saving of return register? If so, then that's your problem. Sub1 saves its return to main, but as soon as sub2 then calls sub1, sub1 saves its return to sub2, wiping out (overlaying/destroying) its previously saved return to main. End result is when sub2 returns back to ITS caller (sub1), sub1 then ends up returning back to sub2 again, not main. You need to use some type of "stack" approach. You need to maintain some type of "nesting level" value that is incremented upon entry and decremented upon exit, which is used to index into an array of return addresses (i.e. the "stack") so you can return back to the correct caller depending on the nesting level. -- "Fish" (David B. Trout) Software Development Laboratories mail: fish@... |
||
|
NESTED SUBROUTINES
I am looking for documentation/examples of how to nest
multiple layers of subroutines in DOS/VS ASM. I can do one-nesting, but if I try to nest two levels main -> sub1 -> sub2 -> sub1 -> main the system seems to hang or loop.? Trying to figure it out for an app that I am writing. Cheers tom c |
||
|
Re: BUFF40 jcl/documentation Fortran
Hi,
I managed to get BUFF40S to work. It probably will not work on DOS/VS. I used DOS/360. You need to define a very small supervisor. It seems it can't be bigger then 16K. BUFF40 does some LH to load pointers to data, if they end up being over 16K they get sign extended and will cause an address exception. Note this will not work under POWER. // ASSGN SYS012,X'191' <---- Disk for BUFF40S file. // ASSGN SYS013,X'00C' <---- Where to get input from // DLBL BUFF40S,'BUFF40.SPOOL.FILE',0,SD // EXTENT SYS012,WRK14A,,,1100,1000 <- 10 to 1000 // UPSI 10000000 <--- Needed for format spool file. // EXEC TSTFORT $COMPILE < Program goes here> $EXECUTE < Data goes here> < Repeat COMPILE/EXECUTE as needed> $COMPILEX /* /& Compile supports the following options: T=# number of seconds to allow to compile P=# number of pages of output to allow C=# number of input cards allowed. E=# number of errors to allow. L=1 enable listing. Defaults: T=20,P=5,C=50,E=25,L=1 Many thanks to Rene Ferland for helping with how to define a file in DOS. Rich - ========================================================================== Richard Cornwell rich@... LinkedIn: ========================================================================== |
||
|
Re: BUFF40 jcl/documentation Fortran
Hi,
toggle quoted message
Show quoted text
I got it to start. It needs a file BUFF40S with between 10 and 100 cylinders. I am not sure how to create files on DOS yet. If anyone can provide the JCL to make this. It directly calls $$BOPEN on the file. The first line of the job should be $COMPILE ????? starting after column 10. Rich Yes, as I said back in 2007, there is no doc other than the source --
========================================================================== Richard Cornwell rich@... LinkedIn: ========================================================================== |
||
|
Re: BUFF40 jcl/documentation Fortran
On Sun, 2 Oct 2022 at 17:14, Joe Monk <joemonk64@...> wrote:
Yes, as I said back in 2007, there is no doc other than the source code. But there is a lot of info in that very tight source, and the line-by-line comments are pretty good if you have experience in that dense style of code.
By the way, I wouldn't say "compiling and linking" about BUFF40, unless you are talking about building it. It's very much a compile and go system - the FORTRAN is compiled into storage and executed there. There is no object deck produced, and so nothing to link. I had thought a couple of people said they had got BUFF40 running not too long after I posted the source, but re-reading, I'm not sure anyone actually got beyond compiling it. :-( Perhaps you can be the first! Tony H. |
||
|
Re: BUFF40 jcl/documentation Fortran
¿ªÔÆÌåÓý>This was from a time when a student would typically submit his program on punch cards and ? Such luxury. I had to put coding forms in the post. It was Fortran II so things like ? F=G*10 ? Usually fails¡¡ ? Dave ? From: [email protected] <[email protected]> On Behalf Of Joe Monk
Sent: 02 October 2022 22:14 To: [email protected] Subject: Re: [H390-DOSVS] BUFF40 jcl/documentation Fortran ? From an old yahoo groups message: ? "There is no doc other than what you find in the source code. BUFF40 is ? Joe ? On Tue, Sep 27, 2022 at 2:36 PM Tom Chandler <tchandler48@...> wrote:
|
||
|
Re: BUFF40 jcl/documentation Fortran
From an old yahoo groups message: a student "compile & go" system designed for high performance on small programs. It does not generate an object deck. The language supported is also a slight variant on standard FORTRAN IV (for example, in a few cases blanks are significant, whereas in proper FORTRAN IV they never are). This was done in order to catch and try to correct many common student errors and allow execution to proceed. This was from a time when a student would typically submit his program on punch cards and get output back the next day, so it was frustrating to make a simple typo and have no execution." Joe On Tue, Sep 27, 2022 at 2:36 PM Tom Chandler <tchandler48@...> wrote: I have BUFF40 compiling and linking via dos/vs.? Does anyone have |
||
|
Re: BUFF40 jcl/documentation Fortran
¿ªÔÆÌåÓýI¡¯d really like to help you Tom but I can¡¯t find my documentation. ? This is a paragraph from my webpage that I wrote for my 50th anniversary at SRU. ? The first computer usage by students was in 1970 for FORTRAN classes.? Their programs were compiled with a stand-alone program called RAX.? We had to shutdown DOS in order to??RAX.? Later we acquired BUFF40, a fast FORTRAN compiler from the State University of New York at Buffalo.? It ran in DOS/360. ? I don¡¯t remember for sure but I think there might have been a WATFOR or WATFIV compiler that would run on DOS that came after BUFF40. ?
? From: [email protected] <[email protected]> On Behalf Of Tom Chandler
Sent: Tuesday, September 27, 2022 3:36 PM To: [email protected] Subject: [H390-DOSVS] BUFF40 jcl/documentation Fortran ? I have BUFF40 compiling and linking via dos/vs.? Does anyone have |
||
Fran Hensler
to navigate to use esc to dismiss