Beginning with A-Shell build 897 of August 2004, PPNs are based on decimal rather than octal notation, and may range to [999,999] instead of the previous limit of [377,377]. The octal scheme was a holdover from days of yore, when bytes were precious and real programmers worked in binary. (The very idea that the disk would be divided into "projects" and "programmers" gives some idea of the amount of dust accumulated on this concept over the years.) As modern programmers have tried to make use of PPNs as a way of organizing real-world categories of things (location numbers, store IDs, client numbers, etc.) they have increasingly found the range of 1-377 octal both limiting and annoying. So when a certain A-Shell dealer dangled an 85 node license in front of us which needed decimal PPNs, we decided it was time to do something about it. Specifically, the new PPN system allows for decimal numbers ranging from 000-999, a nearly four-fold increase over the previous range (or 16-fold if you consider all the combinations of P and PN on a single device.) Not that we recommend subdividing a device into a million (or even a thousand) PPNs, but you can do so if you so desire. In fact, the LIT utilities continue to recognize only 512 unique PPNs per device.

Initially, the theory was to make the octal/decimal choice an option, but it became apparent that it was so entrenched in the code that it seemed best to just do it and get it over with. For the most part, the changeover should be transparent. No changes are needed to existing disk directories or ini files. However, the conversion does have some ripple effect on LITs and possibly applications, the ramifications of which we dedicate ourselves to discussing here.

First, a large number of LIT utilities (essentially any that deal with PPNs) had to be updated, and regrettably, the updated versions are not backward compatible. To provide an easy escape valve, we packages the older versions (with .48A extensions) on the beta page as lit48a.zip, to be downloaded, unzipped, and renamed to .LIT if you decide to revert to an earlier version of A-Shell.

To make it easy to recognize the new LITs, they are all version 3.0 or higher.

(It should go without saying that this is one of those updates you'll want to perform cleanly, i.e. with no users running the old version.)

Second, and most important, is the question of what effect this will have on existing applications. The answer here is "hopefully none". That is to say, we've tried (and may even have succeeded) in making the new version backwards compatible with existing subroutines that retrieve or set PPN values. However, we cannot completely rule out the possibility that an application does some kind of internal manipulation of PPN information using octal conversion utility code. Before worrying about that, we'll first review the general approach we used to upgrading existing subroutines, and then list all that have changed. Based on that, you can probably quickly determine if you have anything to be concerned about.

General principles relating to PPN arguments in subroutines:

•   Any PPN values represented in a pair of B,1 (or a single B,2) parameters have been kept backwards compatible. That is, they will work as before for the existing range of octal PPNs. They will not, however, accommodate new PPNs which require decimal digits or go beyond the previous limit of 377,377.

Note that these B,1 parameters were always a bit awkward, due to the fact that the binary representation only made sense if reformatted as octal. If you used a PRINT statement to print out the B,1 parameters returned from a subroutine such as GETPPN, they would have appeared strange converted to decimal. (For example, [377,100] stored in a pair of B,1 variables and displayed using PRINT would come out as 255,64.)

•   PPN values represented as strings (S,3 or more) are both backwards and upwards compatible. They will work as before and also accommodate PPNs such as [999,888].

•   Any other storage format (for example, a pair of B,2 or F,6) will use the straightforward decimal representation. (Fortunately, there is only one commonly used subroutine that used one of these formats for PPNs: XPPN.SBR.)

Here is the complete list of subroutines affected by this change (with comments) for your review. (Watch out for ALIASes though!)