We're opening up this topic as a place to put your comments, questions, problems, observations, wish-list items, and anything at all related to updating to A-Shell 5.0 from an earlier version (such as 4.8). Hearing from our experienced developer/resellers regarding any "gotchas" or known update problems would be most helpful to those considering or planning such an update.

I'll start it off by listing the known concerns (at least the ones known to me):

1. Decimal PPNs. The biggest potential for application compatibility issues is the conversion from octal to decimal ppns. In most cases this will be transparent and painless, but if you use certain XCALLs to query/set/manipulate PPN values in B,1 format, you may need to make some (hopefully very simple) modifications. The best place to read up on this is in the topic "PPN Numbering" in the Development Guide (under Miscellaneous Topics).

2. New reserved words. This is an issue if you already are, or intend to, compil your programs with the /x:2 switch to take advantage of A-Shell extensions. Since this is not strictly related to updating to A-Shell 5.0, it is addressed in a separate thread in the Program Development forum under the topic Upgrading to compil/x:2

3. LIT commands. Nearly all of the LIT commands in DSK0:[1,4] were modified to deal with the conversion to decimal PPNs. The only issue here is to make sure that you do a full update (including the LIT commands) and don't try to run the ashell 5.0 executable with a previous set of LITs. It is, however, possible to simultaneously run A-Shell 5.0 and A-Shell 4.8 (but not prior to 4.8), sharing the same devices and data, as long as you use a separate DSK0:[1,4] for each.

Update strategy: I've been asked whether there is any reason to undertake a major update in incremental steps, say, by going from 4.6 to 4.8 and then to 5.0, rather than just going directly to 5.0. My answer is: No. I see no advantage in that kind of incremental approach. I do, however, recommend that you set up a test partition or system to test your application with A-Shell 5.0 and to resolve any issues, rather than just updating a production system directly. That said, aside from the issues noted above, I think most people will find the update painless, even when going from 4.6 to 5.0.

Updating from 4.9.987+ to 5.0 will be even more painless, since the decimal PPN and LIT issues, if any, will already have been resolved. In these updates, the main issues will be the addition of reserved words and GUI development subtleties.

Gotme!

Application: A background job monitors a port, when a connection is made it submiits a child to handle the task.

Problem: Working well pre 5.0, now the child does not execute.

Cause: Not having a : after the /L switch in the command line.
SUBMIT CMD:PSSERC.CTL 1133 /L CMD:PSSERC.LOG
need:
SUBMIT CMD:PSSERC.CTL 1133 /L:CMD:PSSERC.LOG

Note: not using the /next or /after switch's and the Ashell command reference doc on SUBMIT does not annote the need for this : after the /L switch.

Solution: Placed a : in place of the space in the xcall in the parent job and all is working well. Hope this helps someone.
(Note: I know I do not need the /L switch to write a log in the ctl's default location, but I am actually naming it something else and writing it in a different location.)

Everyone have a good day now.

Sounds like I fixed one problem and created another. The idea of using spaces between switches and their arguments (e.g. /L logname instead of /L:logname) never was very AMOS-like. They crept in when someone else (who was not familiar with AMOS) originally created SUBMIT.LIT, and it has been half-heartedly preserved over the years, but with increasing difficulty as the command line switches get more complex.

I'm glad you figured out the problem, and I'm glad you've moved to the /L: syntax, but probably I should take another look at SUBMIT to prevent others from stumbling on that issue.

Thanks for the heads-up.

FYI, SUBMIT.LIT 3.1(148) should fix this. It will be included in the 5.0.988 release packages.

Watch out for blowing dust from an old topic.

Version 5.0.985.0

Problem: Running a report, file 805 open in random'forced, READ a record, decide to print info from it, READL the record, set a date in it, WRITE the record. Get a error 29 on the write statement.

Old non changed programs that work on 4.8, 4.9.

Cause: Program did a XCALL SETRO,1 in the begining, SETRO is alias'd to ASFLAG in the miame.ini.

Correction: Remark out XCALL SETRO, final solution will probably be to alias setro to a totally blank sbx in the ini.

Background: Way back when dino's roamed the earth on a network of AIX boxes, reading across the network caused the system to resort to snail mail. Caveman Jack came up with setro,1 and 0 to put the system in/out of read only mode, thus creating reports at blazing lightspeed's. When files where needed to be updated on a large basis, we institued rloging to that box. As we moved to Linux this became a moot point and would just alias this to asflag, which according to ancient legend, was a non binding call. Thus our non-guizied programs have a palethery (sp) of these floating around.

Final: I do not think this will affect anyone else, and I will alias to a non-enity, until final extinction of XCALL SETRO.

You'll have a good week.