[previous page/back on track]
Location --- http://www.mvps.org/dmcritchie/rexx/spf08.htm

SPF/PC Bugs Encountered in SPF/PC

For those familiar with ISPF on the mainframe SPF/PC provides a means of carrying over mainframe skills into the world of PC's. 

Unfortunately it is next to impossible to use macros on both PC's and mainframes.

The bugs described here are based on trying to get macros that work fine on TSO to work in SPF/PC.  One would think this to be a simple matter since the SPF/PC documentation matches that of TSO.  Unfortunately very few macros will run unchanged on both systems. 

Expected Problems that you would encounter

Differences in reading and writing files using REXX coding

Character conversions between ASCII and EBCIDIC

• ascii characters (as represented in HTML):   
  x'5e' / #94 / ^,   
  x'aa' / #170 / ª,   
  x'b5' / #181 / µ,   
  x'ac' / #172 / ¬,   
    What you see above is the HTML representation in ASCII

NOT EQUAL

To make coded macros work across platforms have tried to use  \=,  \=,  or <>  for NOT EQUAL,  instead of ¬=  in TSO, and  ^=  in SPF/PC to avoid conversion problems.  The PLI Not sign is not an original ASCII character.  You will find it in HTML symbols as x'AC', and in SPF/PC as an x'AA' which doesn't make matters any easier.

System considerations

parse version v1 v2 v3 v4 v5
if v1 =

• "REXXSAA" -- running on OS/2
• "REXX/2" -- running on DOS, or Windows
• "REXX370" -- running on mainframe with TSO

BUGS in SPF/PC, and SPF/2        

1. Process return codes do not match documentation (page 4-76, help 40.57).  Incorrect return codes make running on TSO and SPF/PC without changing code impossible.
2. Use of line_after and line_before in a macro incorrectly changes the CURSOR position.  Should have no effect on the cursor position.

   ISPF Edit and Edit Macros SC34-4446-01 Version 4 Release 2 pages 371-372section CURSOR documents only 7 edit commands to change the CURSOR position:
       CHANGE, CURSOR, EXCLUDE, FIND, SEEK, TSPLIT, USER_STATE

   (This is a surprise to me that TSPLIT changes the cursor position, can anyone verify this.  In any case SPF/PC is not functioning in the same manner as TSO within macros.)
3. LINE use will cause dropping of any attached label names at any level when line gets rewritten.
4. TFLOW  is dropping labels on flowed lines, this is a problem when the FIRST line that is flowed.  Probably doesn't matter on the other lines that get flowed since the number of lines can change.
5. TSPLIT   as a primary command correctly splits at the cursor position and correctly leaves the cursor where it is.  Incorrectly realigns split portion with the line that it split away from instead of the next line.
6. TSPLIT   in a macro is not splitting at the cursor position.  It is splitting incorrectly at the position after the cursor (up to six chars beyond) and it is incorrectly changing the cursor position.  This is contrary to both TSO and the way that it works in SPF/PC when not used in a macro. 
   If the non required line and column is added to the command it will split at one column beyond where it is supposed to split. Though it may or may not be predictable within an SPF/PC macro is quite contrary to documentation in that it should split AT the cursor not after.
7. "line_before .zcsr =noteline abc def" creates a dataline when equal sign is next to noteline same for next to msgline.  Should be the same as if there were a blank after the = sign and not create a dataline.
8. LOCATE is moving the cursor position.  Whatever it was in TSO it is not the same in SPF/PC.  SPF/PC is relocating the cursor to the first non-blank character after the located line.  Not sure what TSO did in all cases like when a different page is shown, but on the same page I don't think LOC changed the cursor position.  In any case SPF/PC is not performing LOC in the same manner as TSO.
9. LINENUM return errors only go up to 8.  Not 12, 20.
10. The following is valid and documented for TSO.  It does not work in SPF/PC.  The purpose is to change only the column position of the cursor.
       ISREDIT CURSOR = , col

Summary of most of the Bugs

The following items are about the only items that should affect the cursor position:

• CHANGE, FIND, EXCLUDE, SEEK, CURSOR,

The following items should NOT be moving the cursor:

• TSPLIT, LINE, LINE_AFTER, LINE_BEFORE

The following items are moving the cursor in an incorrect manner

• LOC

The following items are incorrectly dropping labels

• TFLOW, LINE, LINE_AFTER, LINE_BEFORE

The following are yielding invalid Return Codes

• LABEL (RC=4), PROCESS (RC=12), LINENUM (RC=12, RC=20)
• All of the Return Codes should be checked for conformance.  The SPF/PC documentation is correct in this area (it matches ISPF documentation), but SPF/PC is not in conformance to the documentation.

The following problems may have been "fixed"

• ADDRESS "ISPEXEC" ... is correct
• It would be incorrect to not include ADDRESS in TSO either on the line or under an ADDRESS "ISPEXEC" statement.
  • SPF/PC is allowing the Address to be omitted.
  • Of a much more serious nature SPF/PC was NOT allowing the ADDRESS prefix. It appears that SPF/PC may now at least tolerate the ADDRESS prefix allowing the same coding to run on both TSO and SPF/PC. But I haven't had time to check this out fully yet. One critical area was on setting LMSG and SMSG.

Vagueness of messages

1. In SPF/PC all commands were designed to be allowed in lowercase as well as uppercase, or so I was told.  In 4.0.A the "ISREDIT" on the first line must be capitalized or not much will happen.  TSO requires more capitalizations and if one is going from SPF/PC to TSO a simple translate could be performed.
2. Error #16.  Label not found.  -- Before execution does not convey what label is missing.  By the way look for error messages documented in c:\spfpc40\rexx.doc, also check HELP in SPF/PC.  CSIGNAL is a macro to help identify missing labels when you get Error #16.  Missing labels will be shown in NOTE lines.

My thoughts

This is strictly my opinion, but I thought that TSO compatibility was what SPF/PC was supposed to address.  CTC used ISPF under VSE in testing for compatibility and now appears to be abandoning ISPF entirely for a GUI interface with the C language in SPF/SE.  Companies that might have used SPF/PC for development have abandoned it as too incompatible.  The return codes were not observed disregarding both ISPF and CTC's own documentation which of course is the same as ISPF.  Regardless of all of this SPF/PC allows me to work on a PC in a manner similar to what I was used to under TSO.  I like the user supplied enhancement to look at PKZIP files.  I also like the extension of block selection not found in TSO which helps make up for not having a "proper" initial acro facility.  Being able to work in a similar manner is not sufficient to do development work for SAA compliant systems.

Perhaps not bugs but definitely differs from TSO  

1. In TSO you can enter a macroname on the command line and the labels it will use on the same ENTER.  On SPF/PC the labels will disappear as soon as ENTER is hit and will not be found.  You have to hit ENTER to make the labels effective.

   This can result in a hang asking you to hit ENTER, but you cannot.
   line_after .b = noteline "xxxxxxxx"

2. In TSO you can change a labelname or enter CC etc by including one space after the new label or line command.  In SPF/PC the space does not cause the remainder to be ignored.  If you type ".C " over ".BBBBB" you get an unusable label that looks like ".C BBB".

How to Reduce some of the incompatibilities

1. Read all the lines into compound name variables "A.I" and use REXX programming to find strings in data rather than SPF commands.  This would probably result in faster execution but doesn't allow you run the macro in the same fashion as you would using SPF/PC commands outside the macro. Which destroys the reason for using macros instead of programs.
2. Keep track of the CURSOR at all times so you can restore it when SPF/PC incorrectly moves it.
3. Avoid using TSPLIT in macros because it is the most incompatible.

Other problems

1. The Search (=3.b and =3.c) frequently fails. Probably at the point of completion.
   Solution: Use the FIND files or folders off of the Windows 95/NT Start 

   In reality you don't really need to depend on this feature because you can install AltaVista Personal Search on your own computer with all of it's features, and the best part of it is that it is FREE.  Installation on a server is another matter where it's use looks very expensive. 

2. Sometimes runs out of memory or work space and have to reboot to get it to work again.

Some things you have control of in SPF/PC

SPF/SE

SPF/SE imposes limitations of 255 bytes per record on HTML, these limitations simply do not exist on PC or HTML files, it also comes up with a lot of "soft" errors on the following dataset: http://www.mvps.org/dmcritchie/excel/xlindex.htm since I only tested with the demo I can't tell whether it would actually damage an existing file.

Is SPF/SE completely useless?  It is almost completely useless to TSO people who want to use macros  If you don't use macros you can use it as an editor.  You can use the SPF/SE Demo as a browser and that is about as much use as I have for it.

Code for BROWSE.BAT

     c:\spfdemo\bin\spfdemo.exe /b%1

     @echo off
     spfpc %1 /e

Major blunders by CTC

1. Not fixing their bugs in SPF/PC.
2. Not keeping in contact with customers.  For old customers, the addresses and phone numbers in manuals are not current, and they lost their contacts with their original customers.  Contact now for those who reregister is limited to advertising SPF/SE, which for mainframe programmers is utterly useless without complete REXX support (it has none).
3. Not having a proper internet presence, email to tech support, code and fixes -- they do have internet presence, NOW.
4. Getting rid of or losing people who could support REXX.
5. Dropping REXX support at the very time that they could have cleaned up on Y2K conversions. Now by switching to REXX all they could hope for would be to pick up some old programmers, but not much of the way in commercial accounts (which they never really had anyway, IMHO), but which quite frankly are their only hope for a customer base.
6. Potential customers have vast amounts of REXX coding avaiable for use in macros, and no experience or desire in converting any of it to C.

Letter to CTC Sales in response to new SPF/SE version

REXX support was dropped Dec 31, 1998.  I personally think it would be good if everyone who used SPF/PC or SPF/Pro indicated to CTC what they think about the dropping of support for REXX, and IFPS in favor of SPF/SE.

Trademarks

SPF/PC® and SPF/SE® are registered trademarks of Command Technology Corporation.

and this stuff and a heck of a lot more is all IBM's

OS/390, SPF, ISPF, Dialog Manager (DM), Program Development Manager (DM).

Visitors, to this page since May 30, 1997.

Comments

Copyright (c) 1997, 2000 F. David McRitchie
[previous page/back on track] or use web browser BACK key to return to previous page.