What's the rationale here?

We're trying to get the address of a common region.

COMRG

L 1,20
SVC 33

LR R5,R1
USING COMREG,R5

The first thing it does is load a value from absolute address 20.

And then it does an SVC 33 - which provides a level of
abstraction I think. But you've just defeated that abstraction
by accessing an absolute address. If you're willing to start
at an absolute address, you may as well have your control
blocks chained off that. Perhaps this isn't considered to be
a control block - it is specific to this program and there
could be a chain of such programs.

Or alternatively - use the abstraction - SVC 33 can go and
inspect low memory itself?

Or is that not how the PSA works when there are multiple processors
or something like that?

Thanks. Paul.

Paul Edwards wrote:

What's the rationale here?

We're trying to get the address of a common region.

COMRG

L 1,20
SVC 33

LR R5,R1
USING COMREG,R5

The first thing it does is load a value from absolute address 20.

And then it does an SVC 33 - which provides a level of
abstraction I think. But you've just defeated that abstraction
by accessing an absolute address. If you're willing to start
at an absolute address, you may as well have your control
blocks chained off that. Perhaps this isn't considered to be
a control block - it is specific to this program and there
could be a chain of such programs.

I am going to presume you know what a partition is in DOS/VS.

Each partition has its own Communications Region. Address 20 is always set to the address of the given partition's Communications Region control block by the dispatcher. It is a part of task dispatching. So while that particular partition is running, address 20 always points to its COMRG.

Or alternatively - use the abstraction - SVC 33 can go and
inspect low memory itself?

That is not the purpose of SVC 33.

Or is that not how the PSA works when there are multiple processors
or something like that?

I don't believe DOS/VS supported multiple processors. It only supported multiple partitions. It is just a very simple multitasking operating system.

SVC 33 is, as far as the user is concerned (or should I say, as far as USER tasks are concerned), a dummy SVC that essentially does nothing. It simply goes directly to the dispatcher to return back to the caller.

If a SYSTEM task issues SVC 33 however, it causes the dispatcher to dispatch a higher priority system task instead, if there is one. (User tasks and system tasks are dispatched differently. User task priorities can change (via the operator PRTY command), whereas system tasks have hard coded fixed priorities.)

To better understand the purpose of SVC 33 (i.e. how it works), all one need do is examine the DOS/VS Supervisor code (listing) for it. (Everyone should have a copy of an assembled supervisor listing on their system for reference IMO. You can learn a lot by studying it):


01098 1331+SVC33 EQU * . @DM01378 20100028
1332+* SVC33 IS A DUMMY SVC WHEN ISSUED BY A USER TASK @DM01378 20100828
1333+* SVC33 ISSUED BY A SYSTEM TASK DEACTIVATES TASK @DM01378 20101628
1334+* WHICH IS ACTIVE VIA SELECT BYTE. THIS ALLOWES @DM01378 20102428
1335+* DISPATCHER TO GIVE CONTROL TO ANY HIGHER @DM01378 20103228
1336+* PRIORITY SYSTEM TASK @DM01378 20104028
001098 9500 073D 0073D 1337+ CLI SELECT,ZERO . SVC33 ISSUED BY SYST.TASK @DM01378 20110028
00109C 0786 1338+ BCR E,R6 . NO,GOTO TASK SELECTION @DM01378 20110828
00109E 1876 1339+ LR R7,R6 . SETUP EXIT ADDRESS @DM01378 20111628
0010A0 4140 0083 00083 1340+READYSYS LA R4,READY . SETUP DESELECT ROUT. @DM01378 20112428
1341+* FOLLOWING ROUTINE CLEARS SELECT BITE AND SETS @DM01378 20112528
1342+* SYSTEM TASKS PIBFLAG TO A VALUE CONTAINED IN R4 @DM01378 20112628
0010A4 5850 0794 00794 1343+DESELECT L R5,ASYSBLKX . ADDRESS OF SYS.TASK BLOCK @DM01378 20113228
00000 1344+ USING SYSBLKS,R5 @DM01378 20114028
0010A8 4880 5000 00000 1345+ LH R8,SYSPIBFL . ADDRESS OF SYS.TASK PIBFLAG @DM01378 20114828
00000 1346+ USING SPIBADR,R8 @DM01378 20115628
0010AC 4240 8000 00000 1347+ STC R4,SPIBFLG . SET TASK TO READY OR BOUND @DM01378 20116428
0010B0 9200 073D 0073D 1348+ MVI SELECT,ZERO . DEACTIVATE TASK IN SELECT @DM01378 20117228
0010B4 07F7 1349+ BR R7 . RETURN TO CALLER OR TO EXIT @DM01378 20118028

--
"Fish" (David B. Trout)
Software Development Laboratories

mail: fish@...

On Wed, Sep 11, 2024 at 11:34 PM, Fish Fish wrote:

Each partition has its own Communications Region. Address 20 is always set to
the address of the given partition's Communications Region control block by
the dispatcher. It is a part of task dispatching. So while that particular
partition is running, address 20 always points to its COMRG.

Thanks for that explanation.

Or alternatively - use the abstraction - SVC 33 can go and
inspect low memory itself?

That is not the purpose of SVC 33.

Ok - I had the wrong concept there - thanks.

BFN. Paul.

Yes, you can just inspect low memory to locate the COMRG.

In the early days of COBOL programming in CICS/VS 1.1 on DOS/VS, there was a mechanism that allowed me to define a COBOL area that had a pointer set to 20, and lo and behold you could access the date from the COMRG without issuing an SVC which was not a good idea in a CICS application.? The date was what I needed.? But anything was there for the reading.

By avoiding SVC 33, CICS, the partition, did not lose control.

How COBOL implemented CICS table accesses via a COBOL defined base-address register field was the basis for the pointer.

Just FYI from the early days.? CICS/VS with COBOL applications provided no mechanism for accessing the date (that I recall).? IBM support found my solution "interesting".

Harold Grovesteen

开云体育

This was close to day one on DOS/VS not MVS: CICS 1.1.?? I can not speak to the situation on MVS.? My MVS experience was a couple decades later and my CICS work was as a systems programmer (as we referred to the job in those days).? Not application programmer, as I was in the 70's when my work experience was DOS/VS.

Harold Grovesteen