CLRSCRN MODULE (basic problem)

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

CLRSCRN MODULE (basic problem)

Hercules390 - Vm mailing list
Hello VM/CMS experts,

I tried to call CLRSCRN from a (Stanford) Pascal program,
using a subfunction CMSX, which issues a SVC X'CA' -
works without problems for FILEDEF and other CMS commands.

But with CLRSCRN I get some problems soon after return
(strange ABENDs A0A from some FREEMAIN call).

I now had the idea that maybe this is due to the fact that the
CLRSCRN MODULE gets loaded at address X'20000', where parts
of my Pascal program are. By looking at the MODULE file, it seems
to me that that is indeed the case, there are lots of X'20000' addresses
at the beginning of the file (which is very small, BTW).

So now my questions (which are very basic, IMO):

- MODULEs always are loaded at a fixed address, so in fact they are
not relocatable, right?

- or: is there a way to change the target address at run time,
before issuing the CMS-SVC, see above?

- I recall that there is another (kind of) standard address 0xE000;
what MODULEs use this address, and what sort of MODULEs will I be
able to call using the CMSX interface, how can I know before?

- any other suggestions?

What I will try now: disassemble the CLRSCRN logic and integrate it
into the Pascal runtime or the PASUTILS extension library.

Kind regards

Bernd

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: CLRSCRN MODULE (basic problem)

Hercules390 - Vm mailing list
>
> I tried to call CLRSCRN from a (Stanford) Pascal program,
> using a subfunction CMSX, which issues a SVC X'CA' -
> works without problems for FILEDEF and other CMS commands.
>
> But with CLRSCRN I get some problems soon after return
> (strange ABENDs A0A from some FREEMAIN call).
>
> I now had the idea that maybe this is due to the fact that the
> CLRSCRN MODULE gets loaded at address X'20000', where parts
> of my Pascal program are. By looking at the MODULE file, it seems
> to me that that is indeed the case, there are lots of X'20000' addresses
> at the beginning of the file (which is very small, BTW).
>
> So now my questions (which are very basic, IMO):
>
> - MODULEs always are loaded at a fixed address, so in fact they are
> not relocatable, right?
>
> - or: is there a way to change the target address at run time,
> before issuing the CMS-SVC, see above?
>
> - I recall that there is another (kind of) standard address 0xE000;
> what MODULEs use this address, and what sort of MODULEs will I be
> able to call using the CMSX interface, how can I know before?
>

I think "transient" is the word you are looking for.

On my system there is a CLRSCRN TEXT Y1 on the 19E disk but you need to
reaccess the disk to see it.  You can use this to generate a new load module
that will run in the transient area.  For example:

ACCESS 19E Y
LOAD CLRSCRN (ORIGIN TRANS
GENMOD CLRSCRN

You could then rename the old CLRSCRN MODULE Y2 and copy the new one onto the Y
disk ensuring it has filemode 2.  There may be one more step to regenerate
the shared directory for the Y disk but I seem to be getting away without the
need to do this for some reason...

Regards,
Peter Coghlan
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: CLRSCRN MODULE (basic problem)

Hercules390 - Vm mailing list
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]]
> Sent: 04 March 2017 21:14
> To: [hidden email]
> Subject: Re: [H390-VM] CLRSCRN MODULE (basic problem)
>
> >
> > I tried to call CLRSCRN from a (Stanford) Pascal program, using a
> > subfunction CMSX, which issues a SVC X'CA' - works without problems
> > for FILEDEF and other CMS commands.
> >
> > But with CLRSCRN I get some problems soon after return (strange ABENDs
> > A0A from some FREEMAIN call).
> >
> > I now had the idea that maybe this is due to the fact that the CLRSCRN
> > MODULE gets loaded at address X'20000', where parts of my Pascal
> > program are. By looking at the MODULE file, it seems to me that that
> > is indeed the case, there are lots of X'20000' addresses at the
> > beginning of the file (which is very small, BTW).

If the module has the symbolic information included the MODMAP command will
display it. E.g.

modmap clrscrn

CLR3270  020000

SYSREF   000600

NUCON    000000

Ready; T=0.01/0.01 21:34:17

> >
> > So now my questions (which are very basic, IMO):
> >
> > - MODULEs always are loaded at a fixed address, so in fact they are
> > not relocatable, right?
> >

On VM370 yes. I seem to remember at some point later it became possible to
build re-locatable modules.

> > - or: is there a way to change the target address at run time, before
> > issuing the CMS-SVC, see above?
> >

Not in VM/370 R6

> > - I recall that there is another (kind of) standard address 0xE000;
> > what MODULEs use this address, and what sort of MODULEs will I be able
> > to call using the CMSX interface, how can I know before?
> >
>
> I think "transient" is the word you are looking for.

The issue is that there are only two places where you can load code. So if
you generate CLRSCRN so it runs in the transient area it can't be run from
programs that also run in the transient area....
.. as you have found out if its generated to run in the normal area it can't
be called from normal programs....

There is a RESLIB command included as a user mod in the SixPack that allows
you to load TEXT file as what are in effect nucleus extensions, so at the
high end of the user area to get round the problem.
I added it so that the BREXX interpreter could be used to run both normal
and transient programs.
   

>
> On my system there is a CLRSCRN TEXT Y1 on the 19E disk but you need to
> reaccess the disk to see it.  You can use this to generate a new load
module
> that will run in the transient area.  For example:
>
> ACCESS 19E Y
> LOAD CLRSCRN (ORIGIN TRANS
> GENMOD CLRSCRN
>
> You could then rename the old CLRSCRN MODULE Y2 and copy the new one
> onto the Y disk ensuring it has filemode 2.  There may be one more step to
> regenerate the shared directory for the Y disk but I seem to be getting
away
> without the need to do this for some reason...
>

Its convention that rather than access as "Y2" access it as a lower letter,
but Y" will work.
You need to do to IPL 190 and then do a "savesys CMS" at pause after the IPL
but if its in the same place on the disk the old in memory directory will
work.


> Regards,
> Peter Coghlan
>
>

Dave
G4UGM

> ------------------------------------
> Posted by: Peter Coghlan <[hidden email]>
> ------------------------------------
>
>
> ------------------------------------
>
> Yahoo Groups Links
>
>
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

(unknown)

Hercules390 - Vm mailing list
In reply to this post by Hercules390 - Vm mailing list
I think "transient" is the word you are looking for.
> On my system there is a CLRSCRN TEXT Y1 on the 19E disk but you need to
> reaccess the disk to see it.  You can use this to generate a new load module
> that will run in the transient area.  For example:
>
> ACCESS 19E Y
> LOAD CLRSCRN (ORIGIN TRANS
> GENMOD CLRSCRN
>
>
Unless I'm mistaken....

LOAD CLRSCRN ( ORIGIN TRANS
GENMOD CLRSCRN ( SYSTEM

the SYSTEM option on GENMOD ensures the module is called with a PSW
Protection Key 0 and ensures it is a single record, PSW KEY 0 module

Origin TRANS makes it loaded at X'E000' by 'LOAD' and SYSTEM on then
genmod 'SYSTEM' option makes it as previously stated.

However, CLRSCRN is part of IPF (like FLIST, BROWSE and many more
options), and is not a part of VM/370 R6.

--Ivan



smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: (unknown)

Hercules390 - Vm mailing list


> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]]
> Sent: 04 March 2017 22:50
> To: [hidden email]
> Subject: [H390-VM] (unknown)
>
> I think "transient" is the word you are looking for.
> > On my system there is a CLRSCRN TEXT Y1 on the 19E disk but you need to
> > reaccess the disk to see it.  You can use this to generate a new load
module

> > that will run in the transient area.  For example:
> >
> > ACCESS 19E Y
> > LOAD CLRSCRN (ORIGIN TRANS
> > GENMOD CLRSCRN
> >
> >
> Unless I'm mistaken....
>
> LOAD CLRSCRN ( ORIGIN TRANS
> GENMOD CLRSCRN ( SYSTEM
>
> the SYSTEM option on GENMOD ensures the module is called with a PSW
> Protection Key 0 and ensures it is a single record, PSW KEY 0 module
>
> Origin TRANS makes it loaded at X'E000' by 'LOAD' and SYSTEM on then
> genmod 'SYSTEM' option makes it as previously stated.
>
> However, CLRSCRN is part of IPF (like FLIST, BROWSE and many more
> options), and is not a part of VM/370 R6.
>
> --Ivan
>

I think the one on R6 was one I copied from the VMSHARE archives or from the
Waterloo tape that came with the original R6 distro...

Dave

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: (unknown)

Hercules390 - Vm mailing list
I think the one on R6 was one I copied from the VMSHARE archives or from
the
> Waterloo tape that came with the original R6 distro...
>
> Dave
>
>
Which is fair and square - it's a DIAG 58 call to clear the screen !

--Ivan


smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: CLRSCRN MODULE (basic problem)

Hercules390 - Vm mailing list
In reply to this post by Hercules390 - Vm mailing list
Thank you all for your help and your comments !!

See below ...


Am 04.03.2017 um 22:14 schrieb Peter Coghlan
[hidden email] [H390-VM]:

>
> >
> > - I recall that there is another (kind of) standard address 0xE000;
> > what MODULEs use this address, and what sort of MODULEs will I be
> > able to call using the CMSX interface, how can I know before?
> >
>
> I think "transient" is the word you are looking for.
>
> On my system there is a CLRSCRN TEXT Y1 on the 19E disk but you need to
> reaccess the disk to see it. You can use this to generate a new load
> module
> that will run in the transient area. For example:
>
> ACCESS 19E Y
> LOAD CLRSCRN (ORIGIN TRANS
> GENMOD CLRSCRN
>

I found CLRSCRN TEXT (and CLRSCRN ASSEMBLE, BTW) on the Y disk,
and doing this GENMOD to the transient area solved my problem.

MODMAP on the new MODULE didn't work, because I didn't get the
module map saved to the new module (it has only two records compared
to three of the old module on Y). But anyway, my SHOWHEX PASCAL program
shows the addresses in the MODULE to be OK:

EXEC PASRUN SHOWHEX
Line 1
Pos   1: 0000e000 0000e000 0000e0f8 0000e0f8 000125d6 00000000 00000000
0000015f
  to  32: . . . .  . . . .  . . . 8  . . . 8  . . . O  . . . .  . . . .  
. . . .
Pos  33: 44000003 00000000 00000000 00000000 00000000 00000000 00000000
e9000000
  to  64: . . . .  . . . .  . . . .  . . . .  . . . .  . . . .  . . . .  
Z . . .
Pos  65: 00000000 00000000 00000000 00000e6a
  to  80: . . . .  . . . .  . . . .  . . . .
Line 2
Pos   1: 47f0f00c 07c3d3d9 f3f2f7f0 90ecd00c 18cf5810 c0f0831e 00244010
c0ee4110
  to  32: . 0 0 .  . C L R  3 2 7 0  . . . .  . . . .  . 0 c .  . . .  .
. . .
Pos  33: c0d85820 c0ec8000 c0f49d00 20004760 c02a8312 00584780 c0464720
c0324740
  to  64: . Q . .  . . . .  . 4 . .  . . . -  . . c .  . . . .  . . . .  
. . .
Pos  65: c05e4710 c0c29d00 20004780 c05e4720 c0464710 c0c291b0 00444770
c0469500
  to  96: . ; . .  . B . .  . . . .  . ; . .  . . . .  . B j .  . . . .  
. . n .
Pos  97: 00454770 c0c24800 0046950c 00444780 c0a69508 00444780 c09a958e
00444780
  to 128: . . . .  . B . .  . . n .  . . . .  . w n .  . . . .  . . n .  
. . . .
Pos 129: c0b29102 00444710 c0ba91b0 00444770 c032910c 00444780 c0329d00
20004720
  to 160: . . j .  . . . .  . . j .  . . . .  . . j .  . . . .  . . . .  
. . . .
Pos 161: c09a4710 c0c21bff 58ed000c 980cd014 07fe41f0 000447f0 c0a84110
c0e047f0
  to 192: . . . .  . B . .  . . . .  q . . .  . . . 0  . . . 0  . y . .  
. . . 0
Pos 193: c0325820 c0ec8323 00244720 c0a641f0 000847f0 c0a80000 19000000
20ff0001
  to 224: . . . .  . . c .  . . . .  . w . 0  . . . 0  . y . .  . . . .  
. . . .
Pos 225: 0400e0e8 20000001 00000000 00000000 ffffffff 00000000
  to 248: . . . Y  . . . .  . . . .  . . . .  . . . .  . . . .
Ready; T=0.04/0.08 02:07:57

and it works perfectly, when called from my Pascal programs.

The module map (in the Y module) is in the 3rd record and looks like this:

Line 3
Pos   1: c3d3d9f3 f2f7f040 00020000 00020000 02000000 e2e8e2d9 c5c64040
00000600
  to  32: C L R 3  2 7 0    . . . .  . . . .  . . . .  S Y S R  E F      
. . . .
Pos  33: 00000600 00000000 d5e4c3d6 d5404040 00000000 00000000 00000000
  to  60: . . . .  . . . .  N U C O  N        . . . .  . . . .  . . . .

The layout of the MODULEs seems to be pretty simple;
is there a description anywhere, or can it be told here
without too much words?

The module seems to work with and without the 3rd record (MODULE MAP);
because there is no record tag, how can the loader distinguish the 3rd
record
from a normal "code" record? I guess: the first record is special and has a
certain layout; all records starting from record 2 are code, but how
about the 3rd?

Oh, I see: is the code size determined by the first (four) addresses in
record 1?
Then it would be clear how many code records are needed (the record
length is limited to 65535 bytes, RECFM = V).

Thanks again to you all, I learned a lot during this conversation.

Kind regards

Bernd

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

MODMAP

Hercules390 - Vm mailing list
When issuing MODMAP on some of my Pascal generated Modules
(here as an example the Pascal Compiler pass 1 itself), a correct Module
Map
is shown; that means: a Module Map is produced, although I didn't use any
special parameters on LOAD or GENMOD.

look here:

modmap pascal1

$LIBX025 04AF38
$LI#X025 04AE88
$PASMEM  04AA50
$LIBX022 04A0E8

...

$LIBX002 046298
$PASLIB# 046268
$SNAP021 045198
$SNAP020 044DE8
$SNAP019 044C00
CMSX     04B1B8
$SNAP010 043D00
$SNAP017 043770
$SNAP018 043658
$PASLIB  04ADB0
$SNAP014 0421E0

...

$PASSTOR 03EDA8
ERRMON   03ED66
IHCERRE  03ED9A
IHNERRE  03ED9A
IHNERRM  03ED66
IHOERRE  03ED9A
IHOERRM  03ED66
IHCERRM  03ED66
$PASSNAP 045CA0
          00A028
$PASCSP2 03F102
$PASSYS  03EDA8
$PASTRC  03E0F4
$PASINT  03DF1E
$PASMAIN 03D560
$PRV0147 03D398
$PRV0148 03D0A8

...

$PRV0005 021BA0
$PRV0004 0218C8
$PASCSP  03F0C6
$PRV0003 0215B0
$PRV0002 021450
$PRV0001 0213A0
$PASMAI# 020580
$PASENT  03D8E0
SYSREF   000600
NUCON    000000
Ready; T=0.03/0.18 03:30:11


Two questions:

a) could it be, that a Module Map is produced only for modules
in the standard area (X'20000'), but not in the transient area (X'E000').

b) I know most of these CSECTs; the Pascal compiler produces generic
names like $PRVxxxx for local procedures and $LIBxxxx for local procedures
of external "Modules" (aka separate Pascal program units). Names with
# in it are CSECTs containing constants and static variables. But I
don't yet
understand the CSECT with the blank name at address X'00A028';
any idea?

The origin of every Pascal program is at x'020580'; the area before that
is needed by the startup program XRUNPARM ASSEMBLE, which converts
the CMS tokenized parameter string into an OS style parameter (the compiler
was developed for OS originally).

The size of the compiler (pass 1) is about 170k at the moment.

Kind regards

Bernd



Am 05.03.2017 um 01:23 schrieb Bernd Oppolzer [hidden email]
[H390-VM]:
>
>
> MODMAP on the new MODULE didn't work, because I didn't get the
> module map saved to the new module (it has only two records compared
> to three of the old module on Y). But anyway, my SHOWHEX PASCAL program
> shows the addresses in the MODULE to be OK:  ...


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: MODMAP

Hercules390 - Vm mailing list
You can get the LOAD command used to build the modules to save a map. MODMAP
is really a cludge for when you don't have that option..

 

Dave

 

From: [hidden email] [mailto:[hidden email]]
Sent: 05 March 2017 01:54
To: [hidden email]
Subject: [H390-VM] MODMAP

 






When issuing MODMAP on some of my Pascal generated Modules
(here as an example the Pascal Compiler pass 1 itself), a correct Module Map

is shown; that means: a Module Map is produced, although I didn't use any
special parameters on LOAD or GENMOD.

look here:

modmap pascal1

$LIBX025 04AF38
$LI#X025 04AE88
$PASMEM  04AA50
$LIBX022 04A0E8

...

$LIBX002 046298
$PASLIB# 046268
$SNAP021 045198
$SNAP020 044DE8
$SNAP019 044C00
CMSX     04B1B8
$SNAP010 043D00
$SNAP017 043770
$SNAP018 043658
$PASLIB  04ADB0
$SNAP014 0421E0

...

$PASSTOR 03EDA8
ERRMON   03ED66
IHCERRE  03ED9A
IHNERRE  03ED9A
IHNERRM  03ED66
IHOERRE  03ED9A
IHOERRM  03ED66
IHCERRM  03ED66
$PASSNAP 045CA0
         00A028
$PASCSP2 03F102
$PASSYS  03EDA8
$PASTRC  03E0F4
$PASINT  03DF1E
$PASMAIN 03D560
$PRV0147 03D398
$PRV0148 03D0A8

...

$PRV0005 021BA0
$PRV0004 0218C8
$PASCSP  03F0C6
$PRV0003 0215B0
$PRV0002 021450
$PRV0001 0213A0
$PASMAI# 020580
$PASENT  03D8E0
SYSREF   000600
NUCON    000000
Ready; T=0.03/0.18 03:30:11

 

Two questions:

a) could it be, that a Module Map is produced only for modules
in the standard area (X'20000'), but not in the transient area (X'E000').

b) I know most of these CSECTs; the Pascal compiler produces generic
names like $PRVxxxx for local procedures and $LIBxxxx for local procedures
of external "Modules" (aka separate Pascal program units). Names with
# in it are CSECTs containing constants and static variables. But I don't
yet
understand the CSECT with the blank name at address X'00A028';
any idea?

The origin of every Pascal program is at x'020580'; the area before that
is needed by the startup program XRUNPARM ASSEMBLE, which converts
the CMS tokenized parameter string into an OS style parameter (the compiler
was developed for OS originally).

The size of the compiler (pass 1) is about 170k at the moment.

Kind regards

Bernd

 

 

Am 05.03.2017 um 01:23 schrieb Bernd Oppolzer [hidden email]
<mailto:[hidden email]>  [H390-VM]:

 


MODMAP on the new MODULE didn't work, because I didn't get the
module map saved to the new module (it has only two records compared
to three of the old module on Y). But anyway, my SHOWHEX PASCAL program
shows the addresses in the MODULE to be OK:  ...










Loading...