Re: CMS program management tutorial - Reslib - MACLIB

I should have mentioned that this is why you can't issue the MACLIB command when in CMS SUBSET mode (from within EDIT).  EDIT is occupying 20000...

Bob

--- In [email protected], "Robert O'Hara" <rohara@...> wrote:
>
> Mike,
> 
> There are two problems with your program.  First of all, you need a "fence" at the end of the parameter list to SVC 202:
>          DC    8X'FF'
> Your program is dying because it is being overlaid by the MACLIB command (which I have documented in the help file as a transient command:  it is not -- I will fix that).
> 
> If you do this 
> 
> LOAD SVMAC (ORIGIN 900000
> 
> it will load above MACLIB, which loads at 20000.
> 
> Or you can do this
> 
> RESLIB LOAD SVMAC
> 
> then 
> 
> SVMAC
> 
> and it should work.
> 
> Bob
> 
> --- In [email protected], Mike Stramba <mikestramba@> wrote:
> >
> > Hi Bob,
> > 
> > I just revisited the "RESLIB" technique trying to run another program - MACLIB.
> > 
> > I'm getting erratic results, sometimes it's working, sometimes not.
> > 
> > Is there something special about MACLIB ?
> > 
> > 
> > SVMAC    CSECT
> >          LR    R12,R15
> >          USING SVMAC,R12
> >          LA    R1,MACLIST
> >          SVC   202
> > EXIT     BR    R14
> > MYERR    WRTERM 'ERROR FROM SVC 202'
> >          B     EXIT
> > *
> > MACLIST  DS  0D
> >          DC    CL8'MACLIB'
> > P1       DC    CL8'GEN'
> >          DC    CL8'FOO'
> > FNAME    DC    CL8'GWTO'
> >          REGEQU
> >          END
> > 
> > 
> > On 7/13/10, Robert O'Hara <rohara@> wrote:
> > > So where can CMS programs run?
> > >
> > > 1. The nucleus.  CMS commands such as STATE are part of the nucleus; their
> > > code is resident in memory at all times.
> > >
> > > 2. The user area at x20000.  This is where user programs run by default.
> > > They can be as large as the virtual machine allows.  Programs written in
> > > COBOL, FORTRAN, PL/I, etc all run here.  And the CMS EDIT command runs here.
> > >
> > > 3. The transient area at xE000.  Programs running here can be no larger than
> > > 8K.  Many CMS commands such as LISTFILE run here.  When you invoke CMS
> > > SUBSET mode from within EDIT, you can only run transient commands, because
> > > the editor is occupying the user area.  Thus you can call LISTFILE from your
> > > PL/I program, but not EDIT.
> > >
> > > 4. The CMS shared segment at 15MB in the SixPack.  CMS defines a shared
> > > segment where EDIT, EXEC, and OS simulation code can reside.  But because
> > > the shared segment is not guarenteed to be there (define your VM to 16MB and
> > > it won't be), the above code will run in the user area or self-load into
> > > high memory.
> > >
> > > 5. Resident memory via the RESLIB program.  The SixPack features a program
> > > called RESLIB that lets you in effect dynamically extend the CMS nucleus.
> > > It is similar to NUCXLOAD introduced in VM/SP (but not compatible with it).
> > > These programs reside in high memory.
> > >
> > > In the forthcoming SixpPack v1.2 I use RESLIB to load REXX and the GCCLIB C
> > > runtime routines into high memory.  Thus a REXX program can call any CMS
> > > program, regardless of where it runs.
> > >
> > > So if you want to write a program that invokes EDIT, instead of
> > >    ASSEMBLE CALLEDIT
> > >    LOAD CALLEDIT
> > >    GENMOD CALLEDIT
> > >    CALLEDIT
> > > which will fail, do this:
> > >    ASSEMBLE CALLEDIT
> > >    RESLIB LOAD CALLEDIT
> > >    CALLEDIT
> > > Now your program is resident in high storage; you can repeatedly invoke it
> > > without calling RESLIB again.  Type HELP RESLIB in CMS on the SixPack for
> > > more information.
> > >
> > > Bob
> >
>