[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
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
on various systems and software: TSO, SPF/PC, SPF2, and VSE.
Character conversions between ASCII and EBCIDIC
The method of transfer between mainframe and PC will determine how
characters get translated. The conversions are NOT consistent. The
following characters will present problems between systems, in
conversions or in what you see in SPF/PC.
- 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
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.
Some things simply work differently on the different systems
and some things just don't work correctly in SPF/PC at all.
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
Current maintenance is 4.0.A. Every single item here is a
serious bug, making code non interchangeable. Interchangeability
is what SPF/PC is supposed to be for.
- 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.
- Use of line_after and line_before in a macro incorrectly
changes the CURSOR position. Should have no effect on the
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:
(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.)
CHANGE, CURSOR, EXCLUDE, FIND,
SEEK, TSPLIT, USER_STATE
- LINE use will cause dropping of any attached label names at any
level when line gets rewritten.
- 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
- TSPLIT as a primary command correctly splits at the
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.
- 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.
- "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.
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.
- LINENUM return errors only go up to 8. Not 12, 20.
- 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
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
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
- 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.
- 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
CSIGNAL is a macro to help
identify missing labels when you get Error #16. Missing labels
will be shown in NOTE lines.
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
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
- 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"
- 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
- 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.
- Keep track of the CURSOR at all times so you can restore it
when SPF/PC incorrectly moves it.
- Avoid using TSPLIT in macros because it is the most incompatible.
- 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
you don't really need to depend on this feature because you can install
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.
- 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
Changing screen colors to Black on White, and
Enlarging the screen size.
SPF/SE is supposed to replace SPF/PC, but as already noted it is completely unsuitable for use by people who used TSO because it lacks a REXX macro interface.
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
Code for SPFPC.BAT
spfpc %1 /e
Major blunders by CTC
Major blunders, in my opinion, that CTC made were.
See copy of Email reply to SPF Sales Team, May 21, 2000.
- Not fixing their bugs in SPF/PC.
- 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
is limited to advertising SPF/SE, which for mainframe programmers is
utterly useless without complete REXX support (it has none).
- Not having a proper internet presence, email to tech support,
code and fixes -- they do have internet presence, NOW.
- Getting rid of or losing people who could support REXX.
- 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.
- Potential customers have vast amounts of REXX coding avaiable for
use in macros, and no experience or desire in converting any of it
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.
SPF/PC® and SPF/SE® are registered trademarks of
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.
Please send your comments concerning my page(s) or materials to:
Copyright (c) 1997, 2000 F. David McRitchie
[previous page/back on track] or use web
browser BACK key to return to previous page.