Terry writes:
...
> This is only part of the code
> (didn't feel like typing in any more ot it), but I think you can get the
> idea from this bit.
...
> Sample of the SPL code (please excuse the spacing, but my OCR software is no
> so great.
...
 
ok...typed or OCR'ed?  :)
 
> GET THE PROCESS IDENTIFICATION NUMBER >)
> AND SET PROGRAM CAP TO ALL "I"'S >>
 
The capability poking is easily modified to work in CM on MPE/iX.
Of course, one should examine *why* this is being done.
 
> PIN := PIN.(8.8);
 
I'd replace the above with:
 
   integer procedure mypin;
         option external;
 
 
   pin := mypin;
 
Or, since 'mypin' is undocumented, you could replace it with a call
to the documented PROCINFO intrinsic to get your own PIN.
 
> (( GET THE CURRENT PRIORITY OF THE PROCESS MPE4 >>
> IF PROC'INFO'l.(2:1) THEN OLD'PRIORITY := "CS";
 
I'd replace with either a call to GETPROCINFO or PROCINFO, both documented
intrinsics.
 
> << GET RUN TIME PARAMETER AND RETURN IT TO PROGRAM >>
 
I'd replace with call to GETINFO, a documented intrinsic.
 
> << SET STATUS TO DEFAULT OF ZERO >>
 
> STATUS := 0;
> GETPRIVMODE;
> WHO (MODE,,,USER,GROUP,ACCOUNT,,TERM);
 
PM not needed for WHO, but is needed for the "FCONTROL (1,..." below.
 
> << DISABLE BREAK KEY AND CONTROL Y IN SESSION MODE >>
> IF MODE.(12:2) = I THEN BEGIN
>     FCONTROL (1,14,WORK);
>     FCONTROL (1,16,WORK); END;
 
Delete, replace with user-mode FOPEN of $STDINX, and call FCONTROL with
that file#.
 
> << FIND THE RIGHT DATABASE NAMES >>
...
> DB'FILE := FOPEN (BBUFF,%OOO1,%1340,,,,,,,,,,-400);
[and FREADLABEL/FFILEINFO/FCLOSE/FCHECK calls]
 
...will continue to work in PM just fine.
 
> FCLOSE (DB'FILE,O,O);
> IF <> THEN FILE'ABORT (DB'FILE);
>
> << FIND THE HIGHEST PASSWORD >>
>
> GETUSERMODE;
> MOVE BASE'PASS := "        "; MOVE HIGH'PASS := "        ";
 
Style note: the GETUSERMODE should be *ABOVE* the "FIND THE HIGHEST
PASWORD", since it is *NOT* part of that code, logically, but instead is
the trailing part of the "FIND THE RIGHT DATABASE NAMES" code.
 
 
In the code segment shown, there's no obvious reason for the dirtiest
part: the poking into the PCBX and JIT at the beginning.
There may be subsequent code that assumes you now have various capabilities
you might not have had otherwise (e.g., OP, SM).
 
--
Stan Sieler                                          [log in to unmask]
                                     http://www.allegro.com/sieler.html