Loading ...
Sorry, an error occurred while loading the content.
 

context

Expand Messages
  • kerravon86
    Now that I have COMMAND.COM (EXE) able to execute another executable, I need to make it do it properly enough to at least return to the caller on normal
    Message 1 of 28 , Oct 1, 2010
      Now that I have COMMAND.COM (EXE) able to execute
      another executable, I need to make it do it
      properly enough to at least return to the caller
      on normal termination of a well-behaved program.

      To do that, I need to have context. ie save
      registers and PSW away to be restored at program
      termination. And there's other info I'd like
      to store away too.

      My plan was whenever I get an SVC 42 I would
      allocate a "context block" and save these things,
      and overwrite the "normal" context with the
      ones for the new executable. On program termination
      I would then restore these things and then free
      the "context block".

      Before I go ahead and do that, I'd like to ask -
      does MVS already use such a thing?

      CDE? RB? PRB? ECB?

      If so, I'll use the same name.

      Thanks. Paul.
    • somitcw
      ... The way the MVS ATTACH SVC works is to create a new Task Control Block ( TCB ) and return to caller. The new task is a sub-task of the task that issued the
      Message 2 of 28 , Oct 1, 2010
        --- In hercules-os380@yahoogroups.com,
        "kerravon86" <kerravon86@...> wrote:
        > Now that I have COMMAND.COM (EXE) able to execute
        >another executable, I need to make it do it
        >properly enough to at least return to the caller
        >on normal termination of a well-behaved program.
        > To do that, I need to have context. ie save
        >registers and PSW away to be restored at program
        >termination. And there's other info I'd like
        >to store away too.
        > My plan was whenever I get an SVC 42 I would
        >allocate a "context block" and save these things,
        >and overwrite the "normal" context with the
        >ones for the new executable. On program termination
        >I would then restore these things and then free
        >the "context block".
        > Before I go ahead and do that, I'd like to ask -
        >does MVS already use such a thing?
        > CDE? RB? PRB? ECB?
        > If so, I'll use the same name.
        > Thanks. Paul.

        The way the MVS ATTACH SVC works is to create a
        new Task Control Block ( TCB ) and return to caller.
        The new task is a sub-task of the task that issued
        the ATTACH SVC but both compete for resources.
        Often, the main-task waits on an Event Control
        Block ( ECB ) that is POSTed when the sub-task ends
        normally or abends. If multiple sub-tasks ( TCBs )
        are created, a multiple WAIT is sometimes used.
        i.e. One WAIT SVCs pointing to multiple ECBs.

        In PCP, multiple tasks were not supported.
        The ATTACH SVC worked about the same as LINK.

        CDE keep track of programs that are loaded in memory.

        RB ( PRB, SVRB, IRB ) are request blocks under a TCB.
        A LINK will create a PRB under the same TCB as the caller.
        An SVC will create an SVRB under the same TCB as the caller.
        An IRB is also under some TCB.

        An ECB is a one-word control block used for WAIT and
        POST communication.

        I would suggest that the first step is for the SVC
        interrupt handlers ( and all other interrupt handlers )
        to save the state of what was executing including the
        old PSW, general purpose registers, floating point
        registers, and control registers. Places that didn't
        use floating pointing registers didn't need to save
        or restore floating point registers. If only one
        task did use floating point registers, it was okay.
        You don't really need to save all control registers
        but why not do it to keep things simple?

        Is your dispatcher smart enough to recognize which
        address space ( ASCB ) has a ready task ( TCB not waiting
        on an ECB ) and dispatch as the correct priority?
      • kerravon86
        ... Ok, this is more than I want to do at this spot. BTW, I realised something today - my style of development is permanent test-bed creator . I never sit
        Message 3 of 28 , Oct 1, 2010
          --- In hercules-os380@yahoogroups.com, "somitcw" <somitcw@...> wrote:
          >
          > The way the MVS ATTACH SVC works is to create a
          > new Task Control Block ( TCB ) and return to caller.
          > The new task is a sub-task of the task that issued
          > the ATTACH SVC but both compete for resources.
          > Often, the main-task waits on an Event Control
          > Block ( ECB ) that is POSTed when the sub-task ends
          > normally or abends. If multiple sub-tasks ( TCBs )
          > are created, a multiple WAIT is sometimes used.
          > i.e. One WAIT SVCs pointing to multiple ECBs.

          Ok, this is more than I want to do at this spot.

          BTW, I realised something today - my style of
          development is "permanent test-bed creator".
          I never sit down and write a specific test
          driver (unless I was forced (paid) to do so
          by an employer). I just add one bit of
          functionality at a time and wait for a result.

          > In PCP, multiple tasks were not supported.
          > The ATTACH SVC worked about the same as LINK.

          Ok, this is what I'm after.

          I want to make the attach behave as a link which
          will wait for the executable to return, and ignore
          the wait and detach calls.

          > CDE keep track of programs that are loaded in memory.

          Ok. And isn't this an appropriate place to put
          the context too? Actually, even if it was, forget
          it, I'd better keep it the same in case an MVS
          program tries to scan it.

          > I would suggest that the first step is for the SVC
          > interrupt handlers ( and all other interrupt handlers )
          > to save the state of what was executing including the
          > old PSW, general purpose registers, floating point
          > registers, and control registers. Places that didn't

          I already do this. I created a "CONTEXT"
          structure for this purpose. It is common
          regardless of the interrupt (well, I only
          have SVCs at the moment anyway, but can't
          think of anything that would differ).

          > RB ( PRB, SVRB, IRB ) are request blocks under a TCB.

          Is it really necessary to have 3 different
          structures? Do they need to save different
          info? Or is it the same structure, different
          reason to be using them?

          > A LINK will create a PRB under the same TCB as the caller.

          Ok. So I need one of them. And this is the place
          that I will store the GPRs and PSWs.

          What macro will give me that? I'll copy that
          structure from MVS 3.8j's expansion. Crikey -
          IHARB? Not sure how to untangle that.

          struct {
          RBCOMMON;
          union {
          IRB;
          SVRB;
          }
          }

          ?

          > An SVC will create an SVRB under the same TCB as the caller.

          Ok, so I'll rename my current one to that.

          > An IRB is also under some TCB.

          Ok.

          > An ECB is a one-word control block used for WAIT and
          > POST communication.

          Ok.

          > use floating pointing registers didn't need to save
          > or restore floating point registers. If only one
          > task did use floating point registers, it was okay.
          > You don't really need to save all control registers
          > but why not do it to keep things simple?

          Ok.

          > Is your dispatcher smart enough to recognize which
          > address space ( ASCB ) has a ready task ( TCB not waiting
          > on an ECB ) and dispatch as the correct priority?

          I haven't got the ability to dispatch multiple
          address spaces yet. I have them defined though.

          BFN. Paul.
        • Tony Harminc
          ... Why support ATTACH at all? Virtually no application programs issue ATTACH. They use LINK or LOAD/BALR or rarely XCTL. ... No - the CDE keeps track of a
          Message 4 of 28 , Oct 1, 2010
            On 1 October 2010 11:29, kerravon86 <kerravon86@...> wrote:

            > I want to make the attach behave as a link which
            > will wait for the executable to return, and ignore
            > the wait and detach calls.

            Why support ATTACH at all? Virtually no application programs issue
            ATTACH. They use LINK or LOAD/BALR or rarely XCTL.

            >>    CDE keep track of programs that are loaded in memory.
            >
            > Ok. And isn't this an appropriate place to put
            > the context too? Actually, even if it was, forget
            > it, I'd better keep it the same in case an MVS
            > program tries to scan it.

            No - the CDE keeps track of a program that's been loaded. It has
            nothing to say about who's executing that program code. An executing
            "entity" (task, thread, whatever) can be running code at any location,
            and of course multiple such entities can be running the same code at
            the same time.

            >> A LINK will create a PRB under the same TCB as the caller.
            >
            > Ok. So I need one of them. And this is the place
            > that I will store the GPRs and PSWs.

            Which GPRs and PSW(s?)? You need somewhere to store this stuff when an
            interrupt happens, but that's short-term. During or after your
            interrupt processing, if you decide to dispatch something other than
            the current unit of work (task, thread, whatever), then you need to
            save that stuff for the next time it gets dispatched. That would
            typically be in the TCB.

            > What macro will give me that?  I'll copy that
            > structure from MVS 3.8j's expansion. Crikey -
            > IHARB? Not sure how to untangle that.
            >
            > struct {
            >  RBCOMMON;
            >  union {
            >    IRB;
            >    SVRB;
            >  }
            > }

            As I said, C is a terrible language for doing this kind of thing. The
            problem of UNIONs is partly why IBM invented the PL.8 language.

            Tony H.
          • Gerhard Postpischil
            ... You need to ask yourself how much of MVS behavior are you going to reproduce. 1) When an interrupt occurs, all registers are saved in the PSA. When the
            Message 5 of 28 , Oct 1, 2010
              On 10/1/2010 11:29 AM, kerravon86 wrote:
              >> RB ( PRB, SVRB, IRB ) are request blocks under a TCB.
              >
              > Is it really necessary to have 3 different
              > structures? Do they need to save different
              > info? Or is it the same structure, different
              > reason to be using them?
              >
              >> A LINK will create a PRB under the same TCB as the caller.
              >
              > Ok. So I need one of them. And this is the place
              > that I will store the GPRs and PSWs.
              >
              > What macro will give me that? I'll copy that
              > structure from MVS 3.8j's expansion. Crikey -
              > IHARB? Not sure how to untangle that.

              You need to ask yourself how much of MVS behavior are you going
              to reproduce.

              1) When an interrupt occurs, all registers are saved in the PSA.
              When the interrupt cannot be serviced immediately, the registers
              are saved in the TCB, and the PSW in the latest RB (located via
              TCBRPB).

              2) When the user issues an SVC, it's processed as in 1) above.
              Some SVCs are type 1, meaning that they execute immediately,
              without creating another RB. Most are type 2 (nucleus resident)
              or 3 (or some variation thereof, like 4; residing in LPA), these
              create an SVRB (except program linkage requests, that create a
              PRB).

              3) A privileged program may send a "program execution" request
              to a TCB; that is done with the (optional) CIRB, and an IRB is
              created as the RB in control for that task. That IRB becomes the
              current RB, and no other programs on the chain will get control
              until the IRB finishes and is removed.

              [Prior to JES2/HASP, I had a little program that sat in the I/O
              handler, and fielded unsolicited interrupts; when such an
              interrupt was for a defined device (normally a card reader), it
              made a CIRB request to the master scheduler to issue a START
              READER,ccc command. That way the operators didn't need to start
              readers manually, just ready the deck.]

              4) A privileged program may send a "program execution" request
              to another address space. This uses an SRB that acts as a
              mini-TCB (register save area, but no associated RBs, especially
              no SVRBs).

              You could define a single block to hold all RB information,
              since they all have a common portion. Most application programs
              rarely look at anything other than PSW, registers, and Interrupt
              length and code (and the link word and bit). TCBs are another
              matter; a nosy program might run the RB chain, examine the TIOT
              entries, run the LLS and JPQ (lists of loaded modules), look at
              memory information, processing flags, protect key, examine DEBs
              for I/O, etc.

              The other thing you need to address now is how to handle
              problems. Program checks should produce a diagnostic snap, and
              preferably have a storage and control block dump option. Much
              harder will be control of runaway tasks; OS uses the timer
              interrupt to limit each task, and installation data to set
              limits. Ditto for stalled tasks - how long do you wait for a
              task that is doing absolutely nothing?

              If you don't use virtual storage, the old MVS Time Slice
              processing should be adequate for sharing (each task is assigned
              a minimum time in control of the CPU, then 20 msec. Every time
              it gives up control voluntarily, its minimum is increased, up to
              50 msec.; expiration of the timer results in reduction of the
              time slice value). Some early systems (e.g., MFT I) gave each
              task control until it issued an I/O or similar request that
              implied loss of control, or issued a special WAIT request that
              shifted control to the next TCB; needless to say that didn't
              work very well in practice.



              Gerhard Postpischil
              Bradford, VT
            • Gerhard Postpischil
              ... And on a test two thirds of Chicago high-schoolers said the earth is flat. There is a difference between quantity and quality. If I invoke a program that
              Message 6 of 28 , Oct 1, 2010
                On 10/1/2010 2:10 PM, Tony Harminc wrote:
                > Why support ATTACH at all? Virtually no application programs issue
                > ATTACH. They use LINK or LOAD/BALR or rarely XCTL.

                And on a test two thirds of Chicago high-schoolers said the
                earth is flat. There is a difference between quantity and
                quality. If I invoke a program that is known never to abend, and
                to clean up after itself, then I don't need ATTACH. For a
                program that may fail, stall, or otherwise misbehave, ATTACH is
                fairly painless. For one thing I don't need to worry about
                whether the coder knows enough to do a FREEPOOL after closing DCBs.


                Gerhard Postpischil
                Bradford, VT
              • Tony Harminc
                ... I m not saying that programs shouldn t use ATTACH. I m suggesting that at the level of MVS compatibility that s likely to be provided by this little OS,
                Message 7 of 28 , Oct 1, 2010
                  On 1 October 2010 14:53, Gerhard Postpischil <gerhard@...> wrote:
                  > On 10/1/2010 2:10 PM, Tony Harminc wrote:
                  >> Why support ATTACH at all? Virtually no application programs issue
                  >> ATTACH. They use LINK or LOAD/BALR or rarely XCTL.
                  >
                  > And on a test two thirds of Chicago high-schoolers said the
                  > earth is flat. There is a difference between quantity and
                  > quality. If I invoke a program that is known never to abend, and
                  > to clean up after itself, then I don't need ATTACH. For a
                  > program that may fail, stall, or otherwise misbehave, ATTACH is
                  > fairly painless. For one thing I don't need to worry about
                  > whether the coder knows enough to do a FREEPOOL after closing DCBs.

                  I'm not saying that programs shouldn't use ATTACH. I'm suggesting that
                  at the level of MVS compatibility that's likely to be provided by this
                  little OS, there isn't much point in supporting it, particularly if
                  it's supported PCP-style as LINK. The kind of program that does use
                  ATTACH is likely to expect the ATTACHing and ATTACHed tasks to both
                  run, to run according to their dispatching priorities, to be able to
                  WAIT & POST between each other, and so on. It's also much more likely
                  to be running MVS control blocks like RB(s), TCB(s), etc. Your typical
                  application program does not issue ATTACH.

                  Tony H.
                • PeterH
                  ... Alas, the RB structure was designed way, way, way back in the PCP/MFT/ MVT days. A PRB is short because it only needs to hold some flags, a link field and
                  Message 8 of 28 , Oct 1, 2010
                    On Oct 1, 2010, at 11:44 AM, Gerhard Postpischil wrote:

                    >>> RB ( PRB, SVRB, IRB ) are request blocks under a TCB.
                    >>
                    >> Is it really necessary to have 3 different
                    >> structures? Do they need to save different
                    >> info? Or is it the same structure, different
                    >> reason to be using them?

                    Alas, the RB structure was designed way, way, way back in the PCP/MFT/
                    MVT days.

                    A PRB is short because it only needs to hold some flags, a link field
                    and the OPSW.

                    An SVRB is much, much longer because it also has to hold the GPRs.

                    Similarly, for an IRB (no, not the IRB which is now called the Input
                    Request Block, this IRB is a hardware definition, the other IRB is a
                    software definition).

                    The PSW and the GPRs are not stored in the same block, they are
                    stored one block level behind the next, or one level before the next,
                    subject to one's viewpoint.

                    In addition, the behavior of certain SVCs, most notably ATTACH, is to
                    create the new RB from its own RB; in this case an SVRB (for a Type 2
                    SVC) can become a TCB and a PRB ... no reason to free a bunch of
                    SP255 only to immediately thereafter do a GETMAIN for two elements in
                    SP255.

                    The whole issue of supervisor control was revisited with MVS, and the
                    TCB, RBs, etcetera, were maintained for compatibility, while the
                    entire processor dispatching architecture was augmented or replaced
                    with SRBs and related structures (replaced in the case of IOS as IOS
                    never involves TCBs, except in IECVEXCP, which is really there for
                    compatibility with the application programs which use EXCP and XDAP).

                    It is possible to implement an exquisitely complex application system
                    while using only the job step TCB (which is created by the initiator)
                    and which is never referred to again unless and until the entire
                    application terminates (normally or abnormally, it really doesn't
                    matter).

                    There are more than enough supervisor interfaces and procedures
                    available which facilitates performing an entire complex application
                    system while using only SRB mode.

                    BTDT.
                  • PeterH
                    ... ATTACH simulates LINK almost to the n-th degree. LINK is actually used as a closed subroutine by ATTACH. The behavior of all the program management SVCs,
                    Message 9 of 28 , Oct 1, 2010
                      On Oct 1, 2010, at 12:05 PM, Tony Harminc wrote:

                      > The kind of program that does use
                      > ATTACH is likely to expect the ATTACHing and ATTACHed tasks to both
                      > run, to run according to their dispatching priorities, to be able to
                      > WAIT & POST between each other, and so on. It's also much more likely
                      > to be running MVS control blocks like RB(s), TCB(s), etc.


                      ATTACH simulates LINK almost to the n-th degree.

                      LINK is actually used as a closed subroutine by ATTACH.

                      The behavior of all the program management SVCs, LINK (SVC 6) XCTL
                      (SVC 7), ATTACH (SVC 42) and their "partners in crime" is such that
                      the overall result is the same whether on a single-task system with
                      one partition, such as PCP, a multiple task system with a fixed
                      number of fixed-sized partitions, such as MFT, or a multiple task
                      system with a variable number of variable-sized partitions, such as
                      MVT, or even a multiple task system with an almost unbounded number
                      of partitions, such as MVS.



                      > Your typical
                      > application program does not issue ATTACH.


                      The pathological counter-example is MVT's implementation of TSO,
                      which has literally hundreds of TCBs in a tree structure, all under
                      the Time Sharing Option Control Task.

                      Swap is a separate structure under that task, with very specialized
                      subtasks which initiate Swap Start and Swap End.

                      It was quite an accomplishment to get TSO to work in the first place,
                      and its success pointed the way to invest literally a billion dollars
                      in the development of MVS, which integrated conventional Job
                      Management, TSO's version of Job Management and HASP's and ASP's
                      version of Job Management all under one "roof".
                    • Tony Harminc
                      ... Sure. But not the other way around. A program that issue ATTACH (vs LINK) almost certainly has some reason for it. If program A does a LINK to program B,
                      Message 10 of 28 , Oct 1, 2010
                        On 1 October 2010 15:21, PeterH <peterh5322@...> wrote:
                        >
                        > On Oct 1, 2010, at 12:05 PM, Tony Harminc wrote:
                        >
                        >> The kind of program that does use
                        >> ATTACH is likely to expect the ATTACHing and ATTACHed tasks to both
                        >> run, to run according to their dispatching priorities, to be able to
                        >> WAIT & POST between each other, and so on. It's also much more likely
                        >> to be running MVS control blocks like RB(s), TCB(s), etc.
                        >
                        >
                        > ATTACH simulates LINK almost to the n-th degree.

                        Sure. But not the other way around. A program that issue ATTACH (vs
                        LINK) almost certainly has some reason for it. If program A does a
                        LINK to program B, and program B WAITs on an ECB that it expects
                        program A to POST, it'll be in for a long wait.

                        > LINK is actually used as a closed subroutine by ATTACH.

                        Makes sense. Does LINK in turn use LOAD?

                        > The behavior of all the program management SVCs, LINK (SVC 6) XCTL
                        > (SVC 7), ATTACH (SVC 42) and their "partners in crime" is such that
                        > the overall result is the same whether on a single-task system with
                        > one partition, such as PCP, a multiple task system with a fixed
                        > number of fixed-sized partitions, such as MFT, or a multiple task
                        > system with a variable number of variable-sized partitions, such as
                        > MVT, or even a multiple task system with an almost unbounded number
                        > of partitions, such as MVS.

                        Well, if ATTACH is treated as LINK, then results may vary, as above.

                        >> Your typical application program does not issue ATTACH.
                        >
                        > The pathological counter-example is MVT's implementation of TSO,

                        TSO is hardly what I think of as an application program.

                        > which has literally hundreds of TCBs in a tree structure, all under
                        > the Time Sharing Option Control Task.
                        >
                        > Swap is a separate structure under that task, with very specialized
                        > subtasks which initiate Swap Start and Swap End.

                        You're talking of MVT/SVS TSO, which was indeed a bit of a miracle.

                        > It was quite an accomplishment to get TSO to work in the first place,
                        > and its success pointed the way to invest literally a billion dollars
                        > in the development of MVS, which integrated conventional Job
                        > Management, TSO's version of Job Management and HASP's and ASP's
                        > version of Job Management all under one "roof".

                        Many other IBMers have further hacked at it since, giving us such joys
                        as APPC and BPX initiators, job IDs that are not generated by the JES,
                        etc. etc.

                        Tony H.
                      • PeterH
                        ... No. LINK is a separate function from LOAD, although both use PROGRAM FETCH as a closed subroutine.
                        Message 11 of 28 , Oct 1, 2010
                          On Oct 1, 2010, at 12:44 PM, Tony Harminc wrote:

                          >
                          >> LINK is actually used as a closed subroutine by ATTACH.
                          >
                          > Makes sense. Does LINK in turn use LOAD?

                          No.

                          LINK is a separate function from LOAD, although both use PROGRAM
                          FETCH as a closed subroutine.
                        • kerravon86
                          ... Whoah! You mean z/OS has moved on to using SRBs, and I can simply use SRBs, with a (near) empty list of TCBs and RBs to fool old programs? So what exactly
                          Message 12 of 28 , Oct 1, 2010
                            --- In hercules-os380@yahoogroups.com, PeterH <peterh5322@...> wrote:
                            >
                            > The whole issue of supervisor control was
                            > revisited with MVS, and the
                            > TCB, RBs, etcetera, were maintained for compatibility, while the
                            > entire processor dispatching architecture was augmented
                            > or replaced
                            > with SRBs and related structures (replaced in the
                            > case of IOS as IOS

                            Whoah! You mean z/OS has moved on to using SRBs,
                            and I can simply use SRBs, with a (near) empty list
                            of TCBs and RBs to fool old programs?

                            So what exactly is the advantage of an SRB? And for
                            that matter, what is an SRB?

                            Thanks. Paul.
                          • PeterH
                            ... Global SRBs are first in the (dispatcher s) priority list. Local SRBs are somewhat down the list. TCBs are at the very bottom. SRBs have been with us since
                            Message 13 of 28 , Oct 1, 2010
                              On Oct 1, 2010, at 4:08 PM, kerravon86 wrote:

                              > So what exactly is the advantage of an SRB? And for
                              > that matter, what is an SRB?

                              Global SRBs are first in the (dispatcher's) priority list.

                              Local SRBs are somewhat down the list.

                              TCBs are at the very bottom.

                              SRBs have been with us since MVS Rel. 2.

                              SRBs were taught at the IBM education centers since at least 1974,
                              perhaps earlier.



                              > Whoah! You mean z/OS has moved on to using SRBs,
                              > and I can simply use SRBs, with a (near) empty list
                              > of TCBs and RBs to fool old programs?



                              I have done so since at least MVS Rel. 3.6.

                              And, that is a HELL of a long time ago.
                            • kerravon86
                              ... All my application programs - brexx, bwbasic etc use ATTACH rather than LINK. The reason they do this is not because they need ATTACH multiprocessing, but
                              Message 14 of 28 , Oct 1, 2010
                                --- In hercules-os380@yahoogroups.com, Tony Harminc <tharminc@...> wrote:
                                >
                                > I'm not saying that programs shouldn't use ATTACH. I'm suggesting that
                                > at the level of MVS compatibility that's likely to be provided by this
                                > little OS, there isn't much point in supporting it, particularly if
                                > it's supported PCP-style as LINK. The kind of program that does use
                                > ATTACH is likely to expect the ATTACHing and ATTACHed tasks to both
                                > run, to run according to their dispatching priorities, to be able to
                                > WAIT & POST between each other, and so on. It's also much more likely
                                > to be running MVS control blocks like RB(s), TCB(s), etc. Your typical
                                > application program does not issue ATTACH.

                                All my application programs - brexx, bwbasic etc
                                use ATTACH rather than LINK. The reason they do
                                this is not because they need ATTACH multiprocessing,
                                but because they were written by a professional
                                (not me) who knows about subtleties like FREEPOOL.

                                The professional nature of PDPCLIB is why it's a
                                one-stop shop for all your MVS-specific needs. In
                                fact, I say MVS, but really, this was designed for
                                z/OS.

                                So that's ALL of my applications. ALL using ATTACH.
                                ALL set in stone to use ATTACH. ALL set in stone
                                to run on z/OS, not PDOS, which is merely a late
                                April Fool's joke.

                                I would not compromise the professionalism of
                                PDPCLIB-based applications to cater for an April
                                Fool's joke.

                                So. PDOS is based around the existing applications,
                                not the other way around. The existing applications
                                already call ATTACH, for good reasons that
                                professionals are aware of, and now - to some limited
                                extent - remember - April Fool's jokes don't need
                                to be too elaborate - I want to make the set-in-stone
                                ATTACH call do something "interesting", where
                                "interesting" = "LINK".

                                No more, no less.

                                The LINK is in fact already working to the extent
                                that the new program actually runs. But I knew at
                                the time I was writing it that I needed some sort
                                of stacking to allow it to return to the caller.

                                So my question is about stacking, not about the
                                merits or otherwise of using ATTACH when you
                                really only want to do a LINK.

                                So far I am in a bit of a mess with SVRB, SRB, PRB,
                                but to actually get a result, I think I'll just
                                create a simple structure SVRB, have a guess at
                                some offsets, and wait until I encounter something
                                that isn't catered for by my simple SVRB, and then
                                revisit *RB at that point.

                                Oh, another thing I don't yet know is if SVRBs are
                                in a self-maintained linked list, or the linking
                                is separate, or whether it is an array. I assume
                                it is number 1, so just need to find the variable
                                name.

                                BFN. Paul.
                              • PeterH
                                ... SVRBs are sometimes dispensed using an accelerated method to allocate and reclaim them, originally called quickcells . No matter, all RBs, of whatever
                                Message 15 of 28 , Oct 1, 2010
                                  On Oct 1, 2010, at 4:21 PM, kerravon86 wrote:

                                  > Oh, another thing I don't yet know is if SVRBs are
                                  > in a self-maintained linked list, or the linking
                                  > is separate, or whether it is an array. I assume
                                  > it is number 1, so just need to find the variable
                                  > name.

                                  SVRBs are sometimes dispensed using an accelerated method to allocate
                                  and reclaim them, originally called "quickcells".

                                  No matter, all RBs, of whatever kind, are in supervisor storage and
                                  are maintained sequentially in non-contiguous storage.
                                • kerravon86
                                  ... Sorry, could you elaborate on that please? Is a single buffer allocated for all RBs? As a stack? Or is it mixed in with other control blocks (ie a general
                                  Message 16 of 28 , Oct 1, 2010
                                    --- In hercules-os380@yahoogroups.com, PeterH <peterh5322@...> wrote:
                                    >
                                    > > Oh, another thing I don't yet know is if SVRBs are
                                    > > in a self-maintained linked list, or the linking
                                    > > is separate, or whether it is an array. I assume
                                    > > it is number 1, so just need to find the variable
                                    > > name.
                                    >
                                    > SVRBs are sometimes dispensed using an accelerated
                                    > method to allocate
                                    > and reclaim them, originally called "quickcells".
                                    >
                                    > No matter, all RBs, of whatever kind, are in supervisor storage and
                                    > are maintained sequentially in non-contiguous storage.

                                    Sorry, could you elaborate on that please?

                                    Is a single buffer allocated for all RBs? As
                                    a stack?

                                    Or is it mixed in with other control blocks
                                    (ie a general stack)?

                                    And either way, is the stack done per address
                                    space or global for all?

                                    Thanks. Paul.
                                  • Gerhard Postpischil
                                    ... The current RB is pointed to be TCBRPB. Each RB (offset 1C) point to the next (older) RB, and the last points back to the TCB (also has the TCB next flag
                                    Message 17 of 28 , Oct 1, 2010
                                      On 10/1/2010 7:21 PM, kerravon86 wrote:
                                      > Oh, another thing I don't yet know is if SVRBs are
                                      > in a self-maintained linked list, or the linking
                                      > is separate, or whether it is an array. I assume
                                      > it is number 1, so just need to find the variable
                                      > name.

                                      The current RB is pointed to be TCBRPB. Each RB (offset 1C)
                                      point to the next (older) RB, and the last points back to the
                                      TCB (also has the TCB next flag on). MVS maintains reserved
                                      system storage - CSA, and per address space SQA. All protected
                                      control blocks come out of various subpools of these (there is
                                      an ATL version of each on later systems). Using subpools and
                                      address space associated areas makes cleanup easier - once I/o
                                      is finished and DCBs closed, the whole thing can be discarded
                                      without individual freeing of separate blocks.


                                      Gerhard Postpischil
                                      Bradford, VT
                                    • kerravon86
                                      ... This field in IHARB? 00001C 3228+RBRSV050 DS A - RESERVED ... 00004B 3082+XSTAB2 DS
                                      Message 18 of 28 , Oct 1, 2010
                                        --- In hercules-os380@yahoogroups.com, Gerhard Postpischil <gerhard@...> wrote:
                                        >
                                        > On 10/1/2010 7:21 PM, kerravon86 wrote:
                                        > > Oh, another thing I don't yet know is if SVRBs are
                                        > > in a self-maintained linked list, or the linking
                                        > > is separate, or whether it is an array. I assume
                                        > > it is number 1, so just need to find the variable
                                        > > name.
                                        >
                                        > The current RB is pointed to be TCBRPB. Each RB (offset 1C)

                                        This field in IHARB?

                                        00001C 3228+RBRSV050
                                        DS A - RESERVED

                                        > point to the next (older) RB, and the last points back to the
                                        > TCB (also has the TCB next flag on). MVS maintains reserved

                                        00004B 3082+XSTAB2 DS B -
                                        00080 3083+RBTCBNXT EQU BIT0 -

                                        > system storage - CSA, and per address space SQA. All protected
                                        > control blocks come out of various subpools of these (there is
                                        > an ATL version of each on later systems). Using subpools and
                                        > address space associated areas makes cleanup easier - once I/o
                                        > is finished and DCBs closed, the whole thing can be discarded
                                        > without individual freeing of separate blocks.

                                        Ok, currently I have effectively defined a BTL
                                        CSA then, using memmgr to manage. However, it
                                        is simple enough to define the others as required.

                                        BFN. Paul.
                                      • PeterH
                                        ... For historical reasons, and for compatibility with MVT s TSO, certain system control blocks are in SP 255. These are swapped-out when the address space is
                                        Message 19 of 28 , Oct 1, 2010
                                          On Oct 1, 2010, at 4:59 PM, kerravon86 wrote:

                                          > And either way, is the stack done per address
                                          > space or global for all?

                                          For historical reasons, and for compatibility with MVT's TSO, certain
                                          system control blocks are in SP 255. These are swapped-out when the
                                          address space is swapped-out. Obviously, these are not swapped in a
                                          non-TSO environment.

                                          MVT's TSO also introduced another set of subpools, most notably SP
                                          245, which is identical to SP 255, meaning it is treated in the same
                                          way, except these are not swapped-out.

                                          It is difficult to make generalizations about subpools as one would
                                          have to know GETMAIN/FREEMAIN pretty well.

                                          For instance, the save area which the the initiator allocates for the
                                          first job step task is in SP 250, which is treated just like SP 0,
                                          except it is owned by the initiator.

                                          SP 253 is were a lot of data management control blocks reside. The
                                          DEB, for example.

                                          There are no stacks. Additional blocks are allocated when needed and
                                          are usually never freed unless and until the job step task
                                          terminates, and possibly not even then.

                                          There are special subpools with special functions, such as SP 247
                                          which is used to allocate and free an entire region.
                                        • PeterH
                                          ... A job step task need only SCHEDULE one SRB which, in turn, can spawn perhaps hundreds, if not thousands of SRBs [ * ] . SRBs are limited to using branch
                                          Message 20 of 28 , Oct 1, 2010
                                            On Oct 1, 2010, at 4:18 PM, PeterH wrote:

                                            >> Whoah! You mean z/OS has moved on to using SRBs,
                                            >> and I can simply use SRBs, with a (near) empty list
                                            >> of TCBs and RBs to fool old programs?
                                            >
                                            > I have done so since at least MVS Rel. 3.6.

                                            A job step task need only SCHEDULE one SRB which, in turn, can spawn
                                            perhaps hundreds, if not thousands of SRBs [ * ] .

                                            SRBs are limited to using branch entries for system services, in most
                                            cases, but almost anything, even basic I/O operations, can be
                                            completely managed within SRB mode.

                                            Certainly not the basic access methods themselves, but it is
                                            certainly possible to simulate SAM or BPAM or BDAM or the like. Even
                                            VTAM and VSAM have special so-called "fast paths" which operate only
                                            in SRB mode.

                                            If you need to do something which is clearly task-mode-oriented, such
                                            as issuing a WTO, you can queue a work element to a subtask of the
                                            job step task who's sole function it is to issue WTOs.

                                            The limitations are bounded only by one's imagination, and specific
                                            system internals experience.


                                            [ * ] Here, I reject the subterfuge of issuing an EXCP, while knowing
                                            full well that MVS' EXCP "back end" is always SCHEDULED in SRB mode,
                                            and then using that as a way of instantiating an SRB process or
                                            processes. One would have to know the MVS IOS (IECVEXCP) differences
                                            with MVT IOS (IECXCP) in order to be successful with that subterfuge.
                                          • Gerhard Postpischil
                                            ... The above doesn t look right. I recall it as being offset 1C, but can t check right now because my Hercules is down while I m running Windows backups. The
                                            Message 21 of 28 , Oct 2, 2010
                                              On 10/1/2010 8:54 PM, kerravon86 wrote:
                                              > This field in IHARB?
                                              >
                                              > 00001C 3228+RBRSV050
                                              > DS A - RESERVED
                                              >
                                              >> point to the next (older) RB, and the last points back to the
                                              >> TCB (also has the TCB next flag on). MVS maintains reserved
                                              >
                                              > 00004B 3082+XSTAB2 DS B -
                                              > 00080 3083+RBTCBNXT EQU BIT0 -

                                              The above doesn't look right. I recall it as being offset 1C,
                                              but can't check right now because my Hercules is down while I'm
                                              running Windows backups. The RBTCBNXT flag is the one indicating
                                              the last/oldest RB in the chain.

                                              As to Quickcells - it's a nifty new feature IBM introduced in
                                              the eighties. If your program, or system component, does a lot
                                              of GETMAIN/FREEMAIN or STORAGE calls for the same or fairly
                                              close size, the Quickcell service may be used instead. You
                                              initialize it by telling it what storage (cell) size you want,
                                              and the maximum number, and whether or not you allow it to
                                              expand if it runs out of cells. After that your calls for
                                              storage get a pre-allocated cell, avoiding GETMAIN overhead; the
                                              code maintains a bit flag for each cell (allocated/free). If you
                                              need chains, you're responsible for maintaining your own chains.
                                              I have a subroutine and macro that mimics the behavior for MVS
                                              (I use it mainly for trees).

                                              If you design all your control blocks from scratch, you may be
                                              able to make all of them fairly close in size, and use a single
                                              cell pool for all of them.

                                              Gerhard Postpischil
                                              Bradford, VT
                                            • kerravon86
                                              ... Well I went with the rblinkb field, and haven t attempted to get offsets correct yet. Actually it was relatively easy to get that up and working, and have
                                              Message 22 of 28 , Oct 2, 2010
                                                --- In hercules-os380@yahoogroups.com, Gerhard Postpischil <gerhard@...> wrote:
                                                >
                                                > On 10/1/2010 8:54 PM, kerravon86 wrote:
                                                > > This field in IHARB?
                                                > >
                                                > > 00001C 3228+RBRSV050
                                                > > DS A - RESERVED
                                                > >
                                                > >> point to the next (older) RB, and the last points back to the
                                                > >> TCB (also has the TCB next flag on). MVS maintains reserved
                                                > >
                                                > > 00004B 3082+XSTAB2 DS B -
                                                > > 00080 3083+RBTCBNXT EQU BIT0 -
                                                >
                                                > The above doesn't look right. I recall it as being offset 1C,
                                                > but can't check right now because my Hercules is down while I'm
                                                > running Windows backups. The RBTCBNXT flag is the one indicating
                                                > the last/oldest RB in the chain.

                                                Well I went with the rblinkb field, and haven't
                                                attempted to get offsets correct yet.

                                                Actually it was relatively easy to get that up
                                                and working, and have programs correctly returning
                                                to the caller.

                                                Then I started tearing my hair out trying to get
                                                return codes to go back.

                                                I eventually tracked it down to two apparent bugs
                                                in @@SYSTEM (do you agree with the fixes?):

                                                http://pdos.cvs.sourceforge.net/viewvc/pdos/pdos/pdpclib/mvssupa.asm?r1=1.150&r2=1.151

                                                and now it's all working fine.

                                                So if nothing else, let it be said that PDOS
                                                found a bug in PDPCLIB. I normally don't use
                                                system(), let alone inspect the return code,
                                                so this particular thing had never come up.

                                                I'll upload a new version (PDOS/380) after a
                                                couple of more enhancements.

                                                BFN. Paul.




                                                SVC code is 10
                                                welcome to my world
                                                argc = 3
                                                arg 0 is <>
                                                arg 1 is <aBc>
                                                arg 2 is <DeF>
                                                looping for a while
                                                finished looping
                                                SVC code is 10
                                                SVC code is 120
                                                SVC code is 120
                                                SVC code is 20
                                                SVC code is 120
                                                SVC code is 10
                                                SVC code is 10
                                                SVC code is 120
                                                SVC code is 120
                                                SVC code is 20
                                                SVC code is 120
                                                SVC code is 10
                                                SVC code is 10
                                                SVC code is 120
                                                SVC code is 120
                                                SVC code is 20
                                                SVC code is 120
                                                SVC code is 10
                                                SVC code is 120
                                                SVC code is 120
                                                SVC code is 3
                                                SVC code is 1
                                                SVC code is 62
                                                SVC code is 10
                                                rc from program is 5
                                                finished running world
                                                thankyou for using pcomm!
                                                SVC code is 10
                                                SVC code is 120
                                                SVC code is 120
                                                SVC code is 20
                                                SVC code is 120
                                                SVC code is 10
                                                SVC code is 10
                                                SVC code is 120
                                                SVC code is 120
                                                SVC code is 20
                                                SVC code is 120
                                                SVC code is 10
                                                SVC code is 10
                                                SVC code is 120
                                                SVC code is 120
                                                SVC code is 20
                                                SVC code is 120
                                                SVC code is 10
                                                SVC code is 120
                                                SVC code is 120
                                                SVC code is 3
                                                return from PCOMM is 0
                                              • Gerhard Postpischil
                                                ... I have no idea how your changes could get correct return codes. 1) Lines 1583/1584 set R11 to point to the caller s SAVE area, from whence R15 is
                                                Message 23 of 28 , Oct 2, 2010
                                                  On 10/2/2010 8:32 AM, kerravon86 wrote:
                                                  > Then I started tearing my hair out trying to get
                                                  > return codes to go back.
                                                  >
                                                  > I eventually tracked it down to two apparent bugs
                                                  > in @@SYSTEM (do you agree with the fixes?):
                                                  >
                                                  > http://pdos.cvs.sourceforge.net/viewvc/pdos/pdos/pdpclib/mvssupa.asm?r1=1.150&r2=1.151
                                                  >
                                                  > and now it's all working fine.

                                                  I have no idea how your changes could get "correct" return codes.

                                                  1) Lines 1583/1584 set R11 to point to the caller's SAVE area,
                                                  from whence R15 is reloaded. Your change from R15 to R13 causes
                                                  it to point to the wrong save area, from which nothing will ever
                                                  be reloaded.

                                                  2) 1727/1728 should suffice to fix any (unreported) problems you
                                                  were having. When I converted from re-usable to re-entrant,
                                                  somehow I missed that reload. The old code was iffy - it might
                                                  or might not return correct data.

                                                  I don't have the current FUNHEAD/FUNEXIT macros, but the GETMAIN
                                                  and FREEMAIN should be done in there, precisely to prevent
                                                  careless errors.




                                                  Gerhard Postpischil
                                                  Bradford, VT
                                                • kerravon86
                                                  ... Apologies, I originally meant to include the expansion: 2765 @@SYSTEM FUNHEAD , ISSUE OS OR TSO COMMAND 2766+ ENTRY @@SYSTEM 2767+
                                                  Message 24 of 28 , Oct 2, 2010
                                                    --- In hercules-os380@yahoogroups.com, Gerhard Postpischil <gerhard@...> wrote:
                                                    >
                                                    > On 10/2/2010 8:32 AM, kerravon86 wrote:
                                                    > > Then I started tearing my hair out trying to get
                                                    > > return codes to go back.
                                                    > >
                                                    > > I eventually tracked it down to two apparent bugs
                                                    > > in @@SYSTEM (do you agree with the fixes?):
                                                    > >
                                                    > > http://pdos.cvs.sourceforge.net/viewvc/pdos/pdos/pdpclib/mvssupa.asm?r1=1.150&r2=1.151
                                                    > >
                                                    > > and now it's all working fine.
                                                    >
                                                    > I have no idea how your changes could get "correct" return codes.

                                                    Apologies, I originally meant to include the
                                                    expansion:

                                                    2765 @@SYSTEM FUNHEAD , ISSUE OS OR TSO COMMAND
                                                    2766+ ENTRY @@SYSTEM
                                                    2767+ DROP , Isolate from other code
                                                    2768+@@SYSTEM B *+4+1+9-@@SYSTEM(,R15) SKIP LABEL
                                                    2769+ DC AL1(9),CL(9)'@@SYSTEM' EXPAND LABEL
                                                    2770+ STM R14,R12,12(R13) SAVE CALLER'S REGISTERS
                                                    2771+ LR R12,R15
                                                    2772+ USING @@SYSTEM,R12
                                                    2773 * L R15,4(,R13) OLD SA
                                                    2774 LA R11,16(,R13) REMEMBER THE RETURN COD
                                                    2775 MVC 0(4,R11),=X'04804000' PRESET FOR GETMAIN


                                                    ...



                                                    2950 SYSATEXT LR R1,R13 COPY STORAGE ADDRESS
                                                    2951 L R9,4(,R13) GET CALLER'S SAVE AREA
                                                    2952 LA R0,SYSATDLN GET ORIGINAL LENGTH

                                                    2953 FREEMAIN R,A=(1),LV=(0) AND RELEASE THE STORAGE
                                                    2954+* OS/VS2 RELEASE 3 VERSION -- 10/25/74
                                                    2955+ LA 1,0(0,1) CLEAR HI O
                                                    2956+ SVC 10 ISSUE FREE
                                                    2957 * L R13,4(,R13) RESTORE CALLER'S SAVE AREA
                                                    2958 LR R13,R9
                                                    2959 SYSATRET FUNEXIT , RESTORE REGS; SET RETURN CODES
                                                    2960+SYSATRET LM R14,R12,12(R13) RELOAD ALL
                                                    2961+ BR R14



                                                    > 1) Lines 1583/1584 set R11 to point to the caller's SAVE area,
                                                    > from whence R15 is reloaded.

                                                    I think they were pointing to the caller's caller.

                                                    > Your change from R15 to R13 causes
                                                    > it to point to the wrong save area, from which nothing will ever
                                                    > be reloaded.

                                                    It is reloading fine now.

                                                    > 2) 1727/1728 should suffice to fix any (unreported) problems you
                                                    > were having.

                                                    I didn't have any specific problem with that,
                                                    was just trying to find out why my return code
                                                    wasn't being passed back, found that, said
                                                    "aha", changed it, still didn't work, and then
                                                    left it in anyway.

                                                    > When I converted from re-usable to re-entrant,
                                                    > somehow I missed that reload. The old code was iffy - it might
                                                    > or might not return correct data.

                                                    Ok.

                                                    > I don't have the current FUNHEAD/FUNEXIT macros, but the GETMAIN
                                                    > and FREEMAIN should be done in there, precisely to prevent
                                                    > careless errors.

                                                    I think you need to pass some parameters for
                                                    that to happen.

                                                    Here is what I am using:

                                                    http://pdos.cvs.sourceforge.net/viewvc/pdos/pdos/pdpclib/mvsmacs.mac?view=markup

                                                    If you still disagree with the first change, I'll
                                                    back out that change and confirm that there's
                                                    definitely a problem (but unless you see the
                                                    problem via visual inspection of @@SYSTEM, you'll
                                                    still think it's my compiler etc).

                                                    BFN. Paul.
                                                  • kerravon86
                                                    ... I think @@DYNAL is suffering from the same problem. I ve uploaded an output.txt with the complete listing. Would you be able to review the code here:
                                                    Message 25 of 28 , Oct 8, 2010
                                                      --- In hercules-os380@yahoogroups.com, "kerravon86" <kerravon86@...> wrote:
                                                      >
                                                      >
                                                      >
                                                      > --- In hercules-os380@yahoogroups.com, Gerhard Postpischil <gerhard@> wrote:
                                                      > >
                                                      > > On 10/2/2010 8:32 AM, kerravon86 wrote:
                                                      > > > Then I started tearing my hair out trying to get
                                                      > > > return codes to go back.
                                                      > > >
                                                      > > > I eventually tracked it down to two apparent bugs
                                                      > > > in @@SYSTEM (do you agree with the fixes?):
                                                      > > >
                                                      > > > http://pdos.cvs.sourceforge.net/viewvc/pdos/pdos/pdpclib/mvssupa.asm?r1=1.150&r2=1.151
                                                      > > >
                                                      > > > and now it's all working fine.
                                                      > >
                                                      > > I have no idea how your changes could get "correct" return codes.
                                                      >
                                                      > Apologies, I originally meant to include the
                                                      > expansion:
                                                      >
                                                      > 2765 @@SYSTEM FUNHEAD , ISSUE OS OR TSO COMMAND
                                                      > 2766+ ENTRY @@SYSTEM
                                                      > 2767+ DROP , Isolate from other code
                                                      > 2768+@@SYSTEM B *+4+1+9-@@SYSTEM(,R15) SKIP LABEL
                                                      > 2769+ DC AL1(9),CL(9)'@@SYSTEM' EXPAND LABEL
                                                      > 2770+ STM R14,R12,12(R13) SAVE CALLER'S REGISTERS
                                                      > 2771+ LR R12,R15
                                                      > 2772+ USING @@SYSTEM,R12
                                                      > 2773 * L R15,4(,R13) OLD SA
                                                      > 2774 LA R11,16(,R13) REMEMBER THE RETURN COD
                                                      > 2775 MVC 0(4,R11),=X'04804000' PRESET FOR GETMAIN
                                                      >
                                                      >
                                                      > ...
                                                      >
                                                      >
                                                      >
                                                      > 2950 SYSATEXT LR R1,R13 COPY STORAGE ADDRESS
                                                      > 2951 L R9,4(,R13) GET CALLER'S SAVE AREA
                                                      > 2952 LA R0,SYSATDLN GET ORIGINAL LENGTH
                                                      >
                                                      > 2953 FREEMAIN R,A=(1),LV=(0) AND RELEASE THE STORAGE
                                                      > 2954+* OS/VS2 RELEASE 3 VERSION -- 10/25/74
                                                      > 2955+ LA 1,0(0,1) CLEAR HI O
                                                      > 2956+ SVC 10 ISSUE FREE
                                                      > 2957 * L R13,4(,R13) RESTORE CALLER'S SAVE AREA
                                                      > 2958 LR R13,R9
                                                      > 2959 SYSATRET FUNEXIT , RESTORE REGS; SET RETURN CODES
                                                      > 2960+SYSATRET LM R14,R12,12(R13) RELOAD ALL
                                                      > 2961+ BR R14
                                                      >
                                                      >
                                                      >
                                                      > > 1) Lines 1583/1584 set R11 to point to the caller's SAVE area,
                                                      > > from whence R15 is reloaded.
                                                      >
                                                      > I think they were pointing to the caller's caller.
                                                      >
                                                      > > Your change from R15 to R13 causes
                                                      > > it to point to the wrong save area, from which nothing will ever
                                                      > > be reloaded.
                                                      >
                                                      > It is reloading fine now.
                                                      >
                                                      > > 2) 1727/1728 should suffice to fix any (unreported) problems you
                                                      > > were having.
                                                      >
                                                      > I didn't have any specific problem with that,
                                                      > was just trying to find out why my return code
                                                      > wasn't being passed back, found that, said
                                                      > "aha", changed it, still didn't work, and then
                                                      > left it in anyway.
                                                      >
                                                      > > When I converted from re-usable to re-entrant,
                                                      > > somehow I missed that reload. The old code was iffy - it might
                                                      > > or might not return correct data.
                                                      >
                                                      > Ok.
                                                      >
                                                      > > I don't have the current FUNHEAD/FUNEXIT macros, but the GETMAIN
                                                      > > and FREEMAIN should be done in there, precisely to prevent
                                                      > > careless errors.
                                                      >
                                                      > I think you need to pass some parameters for
                                                      > that to happen.
                                                      >
                                                      > Here is what I am using:
                                                      >
                                                      > http://pdos.cvs.sourceforge.net/viewvc/pdos/pdos/pdpclib/mvsmacs.mac?view=markup
                                                      >
                                                      > If you still disagree with the first change, I'll
                                                      > back out that change and confirm that there's
                                                      > definitely a problem (but unless you see the
                                                      > problem via visual inspection of @@SYSTEM, you'll
                                                      > still think it's my compiler etc).
                                                      >
                                                      > BFN. Paul.
                                                      >

                                                      I think @@DYNAL is suffering from the same problem.

                                                      I've uploaded an output.txt with the complete
                                                      listing.

                                                      Would you be able to review the code here:

                                                      http://pdos.cvs.sourceforge.net/viewvc/pdos/pdos/pdpclib/mvssupa.asm?view=markup

                                                      I have touched the macros, e.g. there were
                                                      changes needed for RMODE ANY support, but if
                                                      I've broken something, I don't know what.

                                                      I've included the relevant bit of the listing
                                                      below. Note that @@DYNAL appears in the listing
                                                      twice, because there is an unrelated stub for
                                                      standalone use.

                                                      Thanks. Paul.




                                                      3177 *********************************************************************
                                                      3178 @@DYNAL FUNHEAD , DYNAMIC ALLOCATION
                                                      3179+ ENTRY @@DYNAL
                                                      3180+ DROP , Isolate from other code

                                                      3181+@@DYNAL B *+4+1+7-@@DYNAL(,R15) SKIP LABEL
                                                      3182+ DC AL1(7),CL(7)'@@DYNAL' EXPAND LABEL
                                                      3183+ STM R14,R12,12(R13) SAVE CALLER'S REGISTERS
                                                      3184+ LR R12,R15

                                                      3185+ USING @@DYNAL,R12
                                                      3186 LA R11,16(,R13) REMEMBER RETURN CODE ADDRESS
                                                      3187 MVC 0(4,R11),=X'04804000' PRESET
                                                      3188 LR R9,R1 SAVE PARAMETER LIST ADDRESS
                                                      3189 LA R0,DYNALDLN GET LENGTH OF SAVE AND WORK AREA
                                                      3190 GETMAIN RC,LV=(0) GET STORAGE
                                                      3191+* OS/VS2 RELEASE 4 VERSION -- 10/21/75
                                                      3192+ CNOP 0,4
                                                      3193+ B *+12-4*1-2*0 BRANCH AROUND DATA
                                                      3194+IHB0196F DC AL1(0) RESERVED
                                                      3195+ DC AL1(0) RESERVED
                                                      3196+ DC AL1(0) SUBPOOL
                                                      3197+ DC BL1'00000000' MODE BYTE *MVS380*
                                                      VERSION OF PDP CLIB SUPPORT


                                                      STMT SOURCE STATEMENT ASM 0201 05.

                                                      3198+ L 15,IHB0196F LOAD GETMAIN PARMS
                                                      3199+ SR 1,1 ZERO RESERVED REG 1
                                                      3200+ SVC 120 ISSUE GETMAIN SVC
                                                      3201 LTR R15,R15 SUCCESSFUL ?
                                                      3202 BZ DYNALHAV YES
                                                      3203 STC R15,3(,R11) SET RETURN VALUES
                                                      3204 B DYNALRET RELOAD AND RETURN
                                                      3205 *
                                                      3206 * CLEAR GOTTEN STORAGE AND ESTABLISH SAVE AREA
                                                      3207 *
                                                      3208 DYNALHAV ST R1,8(,R13) LINK OURS TO CALLER'S SAVE AREA
                                                      3209 ST R13,4(,R1) LINK CALLER'S TO OUR AREA
                                                      3210 LR R13,R1
                                                      3211 USING DYNALWRK,R13

                                                      3212 MVC 0(4,R11),=X'14000001' PRESET FOR PARM LIST ERROR
                                                      3213 MVC DYNLIST(ALLDYNLN),PATLIST INITIALIZE EVERYTHING
                                                      3214 LDINT R4,0(,R9) DD NAME LENGTH
                                                      3215+ L R4,0(,R9) LOAD PARM VALUE
                                                      3216 L R5,4(,R9) -> DD NAME
                                                      3217 LDINT R6,8(,R9) DSN LENGTH
                                                      3218+ L R6,8(,R9) LOAD PARM VALUE
                                                      3219 L R7,12(,R9) -> DATA SET NAME
                                                      3220 * NOTE THAT THE CALLER IS EITHER COMPILER CODE, OR A COMPILER




                                                      3274+ SVC 99 CALL DYNAMIC ALLOCATION
                                                      3275 STH R15,0(,R11) PRIMARY RETURN CODE
                                                      3276 STH R0,2(,R11) REASON CODES
                                                      3277 LTR R5,R5 NEED TO RETURN DDN ?
                                                      3278 BZ DYNALEXT NO

                                                      3279 MVC 0(8,R5),ALLADDN RETURN NEW DDN, IF ANY
                                                      3280 B DYNALEXT AND RETURN
                                                      3281 DYNAXDDN MVC ALLADDN(0),0(R5) COPY DD NAME
                                                      3282 DYNAXDSN MVC ALLADSN(0),0(R7) COPY DATA SET NAME
                                                      3283 * PROGRAM EXIT, WITH APPROPRIATE RETURN CODES
                                                      3284 *
                                                      3285 DYNALEXT LR R1,R13 COPY STORAGE ADDRESS
                                                      3286 L R9,4(,R13) GET CALLER'S SAVE AREA
                                                      3287 LA R0,DYNALDLN GET ORIGINAL LENGTH
                                                      3288 FREEMAIN R,A=(1),LV=(0) AND RELEASE THE STORAGE
                                                      3289+* OS/VS2 RELEASE 3 VERSION -- 10/25/74
                                                      3290+ LA 1,0(0,1) CLEAR HI ORDER BYTE
                                                      3291+ SVC 10 ISSUE FREEMAIN SVC
                                                      3292 L R13,4(,R13) RESTORE CALLER'S SAVE AREA
                                                      3293 DYNALRET FUNEXIT , RESTORE REGS; SET RETURN CODES
                                                      3294+DYNALRET LM R14,R12,12(R13) RELOAD ALL
                                                      3295+ BR R14
                                                      3296 LTORG ,
                                                      3297 =C'IDC0002I'
                                                    • Gerhard Postpischil
                                                      ... 3292 should also be a LR R13,R9 Preferably the FUNEXIT (and FUNHEAD) macros need to be changed to support the case for a FREEMAIN with no condition code
                                                      Message 26 of 28 , Oct 8, 2010
                                                        On 10/9/2010 2:11 AM, kerravon86 wrote:

                                                        > 3285 DYNALEXT LR R1,R13 COPY STORAGE ADDRESS
                                                        > 3286 L R9,4(,R13) GET CALLER'S SAVE AREA
                                                        > 3287 LA R0,DYNALDLN GET ORIGINAL LENGTH
                                                        > 3288 FREEMAIN R,A=(1),LV=(0) AND RELEASE THE STORAGE
                                                        > 3289+* OS/VS2 RELEASE 3 VERSION -- 10/25/74
                                                        > 3290+ LA 1,0(0,1) CLEAR HI ORDER BYTE
                                                        > 3291+ SVC 10 ISSUE FREEMAIN SVC
                                                        > 3292 L R13,4(,R13) RESTORE CALLER'S SAVE AREA
                                                        > 3293 DYNALRET FUNEXIT , RESTORE REGS; SET RETURN CODES
                                                        > 3294+DYNALRET LM R14,R12,12(R13) RELOAD ALL
                                                        > 3295+ BR R14
                                                        > 3296 LTORG ,
                                                        > 3297 =C'IDC0002I'

                                                        3292 should also be a LR R13,R9

                                                        Preferably the FUNEXIT (and FUNHEAD) macros need to be changed
                                                        to support the case for a FREEMAIN with no condition code return
                                                        in R15. I'll look at that soon.



                                                        Gerhard Postpischil
                                                        Bradford, VT
                                                      • Gerhard Postpischil
                                                        ... I had a chance to look over the code. The current version is correct (FUNHEAD, then LA R11,16(,R13). When the macro replaced the simple code, I forgot that
                                                        Message 27 of 28 , Oct 9, 2010
                                                          On 10/9/2010 2:11 AM, kerravon86 wrote:

                                                          >> 2765 @@SYSTEM FUNHEAD , ISSUE OS OR TSO COMMAND
                                                          >> 2766+ ENTRY @@SYSTEM
                                                          >> 2767+ DROP , Isolate from other code
                                                          >> 2768+@@SYSTEM B *+4+1+9-@@SYSTEM(,R15) SKIP LABEL
                                                          >> 2769+ DC AL1(9),CL(9)'@@SYSTEM' EXPAND LABEL
                                                          >> 2770+ STM R14,R12,12(R13) SAVE CALLER'S REGISTERS
                                                          >> 2771+ LR R12,R15
                                                          >> 2772+ USING @@SYSTEM,R12
                                                          >> 2773 * L R15,4(,R13) OLD SA
                                                          >> 2774 LA R11,16(,R13) REMEMBER THE RETURN COD
                                                          >> 2775 MVC 0(4,R11),=X'04804000' PRESET FOR GETMAIN

                                                          I had a chance to look over the code. The current version is
                                                          correct (FUNHEAD, then LA R11,16(,R13). When the macro replaced
                                                          the simple code, I forgot that the macro didn't do the GETMAIN
                                                          and SAVE area swap, which would have required the extra R15
                                                          load. And the reason the macro isn't doing the GETMAIN is a
                                                          design decision - the GETMAIN in the macro is unconditional,
                                                          whereas the coded one in SYSTEM and DYNALL is conditional, with
                                                          a return code rather than abend if the space is unavailable.

                                                          Gerhard Postpischil
                                                          Bradford, VT
                                                        • kerravon86
                                                          ... Thanks. It took a whole day, but I finally tracked down the anomaly . A bug in my line buffering implementation. Plus another bug with PDOS not setting R0
                                                          Message 28 of 28 , Oct 9, 2010
                                                            --- In hercules-os380@yahoogroups.com, Gerhard Postpischil <gerhard@...> wrote:
                                                            >

                                                            > 3292 should also be a LR R13,R9

                                                            Thanks. It took a whole day, but I finally
                                                            tracked down the "anomaly". A bug in my
                                                            line buffering implementation. Plus another
                                                            bug with PDOS not setting R0 = 0 in SVC 99.

                                                            So I've uploaded a new PDOS/380.

                                                            > I had a chance to look over the code. The current version is
                                                            > correct (FUNHEAD, then LA R11,16(,R13). When the macro replaced

                                                            Ok, thanks. I deleted the commented out lines.

                                                            BFN. Paul.
                                                          Your message has been successfully submitted and would be delivered to recipients shortly.