Re: Hooking display file I/O

[Dave McKenzie <davemck@xxxxxxxxxxxxx>]

I remember once when I did something similar, I had trouble with group jobs.  

When the system starts a group job (using the TFRGRPJOB cmd), it creates the 
PCO for the new group job by making a duplicate of the PCO of the originating 
job.  This means that the new job's ptr to the SEPT will be pointing to the 
same storage as the old job is.  In my case, I had put my SEPT in a space 
object in QTEMP.  This works OK--except that if you end the original job 
before the new job, the new job's ptr is pointing into thin air, causing it 
to crash.

When I saw this, I resolved always to put my SEPT in a permanent space object 
in a permanent library.

--Dave


On Sunday 05 August 2001 17:03, Leif Svalgaard wrote:

> here is how I would install my own SEPT (which initially is just a copy
> of IBM's):
>
> DCL SYSPTR .SEPT(6440) BAS(@SEPT);
> DCL DD PCO CHAR(256) BASPCO;
>    DCL SPCPTR @SEPT  DEF(PCO) POS( 1);
>
> DCL DD IBM-SEPT CHAR(103040) BAS(@SEPT);
> DCL DD MY-SEPT  CHAR(103040) BDRY(16);
>
> DCL DD MY-PTR CHAR(16) BDRY(16);
>     DCL SPCPTR .MY-SEPT DEF(MY-PTR) POS(1) INIT(MY-SEPT);
>
> ENTRY * EXT;
>     CPYBWP       MY-SEPT, IBM-SEPT;
>     CPYBWP       PCO, MY-PTR;
>     RTX          *;
>
> Having my own SEPT, I can now change entries. These changes
> will only impact my own process (which is good during testing).
+---
| This is the MI Programmers Mailing List!
| To submit a new message, send your mail to MI400@midrange.com.
| To subscribe to this list send email to MI400-SUB@midrange.com.
| To unsubscribe from this list send email to MI400-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: dr2@cssas400.com
+---