A-Shell Development History

Fix two EZTYP/EZVUE problems introduced in 897. The first caused XCALL EZTYP,FILE to get an error if you didn't pass the two new optional margin arguments (see 897-2 below). The second was that if you did use the left margin, scrolling through the display vertically cleared the left margin area.

897.4.1

(Windows) Fix problem with GUI font changing from fixed pitch to proportional after redrawing the window when the Control (GUI) font has been set to an explicit font and the fixed-pitch-edit font option it set.

897.4.2

(Windows) When selecting the Control (GUI) font menu option, if the font has been set to something other than the default (blank), it now asks if you want to set it back to the default. This was necessary since there was no other way to select a blank font in the selection dialog once a specific font had been selected.

897.4.3

(Linux) A special build is now available of A-Shell/Linux which supports random files larger than 2GB, provided Large File Support (LFS) is enabled in the kernel and you have a filesystem large enough. The A-Shell file size limit in this version is 2^31 records regardless of the record size. (For example, with 128 byte records, you could create a 256GB file.) Sequential and ISAM files > 2GB not yet supported. Note that the only way to identify this version of the ashell executable is to launch it with the -d switch (ashell -d). The version with large file support will display a message indicating "Large File Support". (The message may disappear after about 1.5 seconds depending on your astart.cmd or other startup command.)

897.4.4

(ATE) A stray input character following XCALL XTREE has been removed.

897.3.1

Fix decimal ppn bug with MIAMEX,10 (check ppn operation) so that it remains backward compatible if the P and PN arguments are passed as B,1. To work with the new extended range of PPNs, you'll need to pass larger arguments (either B,2, F,6, or S,3) in which case they will be treated as decimal values (but won't be backwards compatible to pre-897 versions of A-Shell).

897.3.2

(AIX) Fix byte swapping problem under AIX causing SYSTAT to display PPNs larger than 255 incorrectly. (Did not affect Windows or Linux.)

897.2.1

Fix bug with SETJTB.SBR use of B,1 variables for setting PPN (due to decimal PPN change).

897.2.2

EZVUE (aka EZTYP) now supports the ability to set a certain number of of rows at the top and columns at the left of the display off limits (untouched by EZVUE). This might be useful in some applications to allow some parts of of the application screen to remain visible even while displaying a report. You can set these optional top and left margins via two new optional parameters to EZTYP.SBR:

XCALL EZTYP,FILE{,TOPMGN,LEFTMGN}

You can also set them via two new EZSPL configuration file parameters:

TOPMARGIN = #

LEFTMARGIN = #

897.1.1

Fix SETJTB.SBR change ppn operation using the S,3 variables to specify the new PPN. (broken in 897).

Warning: there is still a problem with setjtb.sbr using the b,1 variables - this will require 897.2 or higher, or better yet, just adjust your code to use the s,3 variables instead of the b,1 variables (which has the added bonus of allowing you to use the entire new range of ppns).

897.1.2

COPY.LIT 3.0(119) fixes a bug introduced in 3.0(118) in which the defaulting of wildcarded output PPNs was incorrectly being based on the CURRENT PPN rather than the PPN of the corresponding input file. Technically the bug and fix is in CMDLIN.SYS rather than COPY.LIT, so the next release will have a full new set of LITs (which VERSYS will report as including CMDLIN[28]) but for the moment, COPY is the only critically affected utility.

897.1.3

Regenerate all of the LITs and clean up some minor installation glitches.

897.0.1

PPNs are now 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 now 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 LIT's, 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:

Note that these B,1 parameters were always a bit awkward, due to the fact that the binary representation only made sense if reformated 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.)

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

 

897.0.2

(Windows/ATE) INFLD TYPE |g now implies |G and can be used in all cases to get the Windows-style edit box implementation of INFLD (in A-Shell/Windows or ATE), without any of the automatic substitution of fancier control types (e.g. date picker, time picker, combo box). (Previously you needed to supply |G in all cases, and add |g to turn off the special control types.)

897.0.3

(Windows/ATE) The combo box has been improved in the following ways:

897.0.4

(INFLD GUI) The handling of fixed pitch fonts in the GUI version of INFLD has been improved somewhat. Unlike proportional fonts (which we only scale vertically and let the horizontal size default based on the display aspect ratio and judgement of the font mapper), fixed pitch fonts can be scaled both vertically and horizontally. We use this to ability to try to generate a font that fits within an INFLD edit box in such a way that the box gets filled up when you get to the maximum number of allowed characters for that field. (With proportional fonts, this is out of the question.) Note that because fixed pitch fonts are currently scaled to an integer width in pixels, as a practical matter, the maximum number of characters is not going to exactly fill the box. But it should be reasonably close. If you can't stand that imperfection, you might have to just give up on the GUI version of INFLD and continue to use the text version.

Note that along with the scaling improvements, we've reduced the degree of automatic expansion of small field lengths. Previously, 1 and 2 character fields were expanded by one character (to allow for font size irregularities.) When the fixed pitch option is set, we now only expand single character fields to 2 column (mainly because the edit window border reduces the available size of the field by so much that a single character field is just too skinny to look good.)

897.0.5

(INFLD GUI) Y/N fields converted to checkboxes (using TYPE ||c) now allow the same keyboard shortcuts (1 and 0, plus the Y and N equivalents based on the language definition.)

897.0.6

(XTREE) - Toggling to another application and back again while XTREE has the focus now returns the focus to XTREE. Also, a problem with controls underneat the XTREE bleeding through has been fixed. (Any controls covered by XTREE will now be hidden until XTREE exits.)

897.0.7

(INFLD GUI+XTREE) A new option has been added to the Misc Settings dialog to "Force standard colors in edit boxes". When set, the EBCLR/EFCLR combination passed via the INFCLR parameter to INFLD is ignored and the standard Windows text and edit background colors (typically black text on a white background) are used. This is a mere convenience for applications that were using explicit INFCLR settings that want to experiment with the standard GUI look without going to much work to adjust their INFCLR parameters.

The option also applies to the XTREE color scheme, although here it overrides the TFCLR,TBCLR (text fg/bg) and PFCLR,PBCLR (prompt/title colors) fields of the MMOCLR parameter. Again, this is a convenience when switching to the GUI version from the text version without needing to bother changing your color definitions.

897.0.8

%env% variable expansion has been improved in a few ways. First, you can now use an %env% variable as a partial filename in an OPEN statement. Assuming you have an environment variable USERNAME which equates to "HAL":

OPEN #1, "%USERNAME%01.LST[1,4]", OUTPUT ! opens HAL01.LST[1,4]

Previously, the %env% name had to be followed by a directory separator.

Second, you can now use %env% names on command lines (provided the command retrieves its argument list XCALL LSTLIN, which is true for all the standard A-Shell LITs), e.g.:

.RUN MYERZ:%USERNAME%X

; above is equivalent to RUN MYERZ:HALX

.COPY *.TMP=%USERNAME%:%USERNAME%*.LST

; above is equivalent to COPY *.TMP=HAL:HAL*.LST

Third, you can now use multiple %env% variables within a single filespec or command line (as in the COPY example above).

Finally, %env% variables which are not defined, are now left in place as literals. Previously they were converted to null. This "feature" avoids complications with other users of % in command lines.

897.0.9

APPEND.LIT 2.1(113) now handles long native filenames containing spaces. For example, the following is now legal:

.APPEND TEST.LST=TEST.LST,"%TEMP%\THIS IS A LONG FILE.LST"

897.0.10

AMOS filenames can now be up to 10 characters long (previously 6). Note that to avoid compatibility problems with existing programs, subroutines, and other internal structures which assume a maximum of 6, it is advised that you only use the new longer filenames with data files. (This is where the main demand is anyway, such as to incorporate CCYYMMDD dates into filenames.) Program names longer than 6 characters will be truncated internally to 6 by most LIT and SBR utilities.

897.0.11

DIR.LIT 3.0(132) supports a new switch /L{ONG} which changes the default display layout to accomodate 10.3 format instead of 6.3 format. It also changes the default /W value from 4 columns to 3. As before, filenames exceeding the maximum display length will show a ">" character following the filename.

897.0.12

XTREE now identifies the initially active column (if set via the XTR'COLUMNACTIVE parameter) by showing the column title button in the depressed state (same as if you clicked on it to sort but without the sort order arrow).

897.0.13

SET.LIT 1.2(139) supports two new commands to link A-Shell color palette numbers to Windows desktop colors, to go along with the existing SET TERM SYSBCOLOR #:

SET TERM WINBCOLOR #

SET TERM WINTXTCLR #

The first (WINBCOLOR) sets the "Window Background" color #, which is typically used for the background of small windows such as edit boxes, checkboxes, and listboxes (typically white).

The second (WINTXTCLR) sets the "Window Text" color #, which is typically used for text both on buttons and in edit boxes and listboxes (typically black). Note that the # here is taken from the foreground palette (unlike WINBCOLOR and SYSBCOLOR which both refer to color numbers from the background palette).

Along with SYSBCOLOR, these can now be used via ATE on UNIX servers.

897.0.14

XTREE.SBR now works in the ATS / ATE environment. Note however, that SftTree_IX86_A_45.DLL must be on each client. (If not distributed with ATE, you'll have to copy it from an A-Shell/Windows installation.)