XPPN

xcall XPPN, ppn, device, job, trmdef

XPPN.SBR returns the PPN, Device, Job, and Trmdef in the formats shown below.

Parameters

MAP1 PPN

   MAP2 Project,B,2

   MAP2 Programmer,B,2

MAP1 Device,S,8             ! (e.g. "DSK1:")

MAP1 Job,S,6

MAP1 Trmdef,S,6

 

Comments

A confusing situation arises when PPN values, which by convention are always represented in octal notation (ranging from zero to 377, rather than zero to 255 as they would if represented in decimal), are stored in numeric variables. Since BASIC has no provision for displaying the value of a numeric variable in anything other than decimal, when the PPN [100,200] is stored in the Project and Programmer fields above and later printed using the PRINT statement, they would display (in decimal) as 64 and 128. To display them in their correct format as octal, you could use the MX_OCVT.  

Another approach would be to set SBR=XPPNOCT in the system configuration file, which causes XPPN.SBR to correct for the octal/decimal discrepancy by converting the returned Project and Programmer values such that they display in decimal as if they were octal. Thus, the PPN [100,200] would be returned as Project=100 and Programmer=200, which is probably what you were expecting.

You might wonder why this was not done by default. The reason is that under AMOS, PPNs were stored as a pair of bytes (each byte ranging from zero to 377 octal). For closer compatibility, A-Shell internally uses the same representation, even though it is arguably arbitrary since at the operating system level, PPNs are mapped to directories that are purely text strings. However, many existing BASIC programs and subroutines relied on the fact that PPNs could be stored in a pair of single byte variables, and thus at some point we would have had to deal with the conversion anyway. 377 decimal does not fit in a single byte, which is why this particular subroutine uses the somewhat non-AMOS-like technique of storing the PPN as a pair of two-byte variables. For comparison, GETJTB returns the PPN both as a single two byte field and as a pair of three-byte strings (for binary and octal representations).

History

2009 September, A-Shell 5.1.1159:  Routine modified to support returning data into dynamic variables, such that they expand as needed. Previously, the output data was being truncated to the current size of the variable, or 0 for uninitialized.