This is a long, rambling note on misc. IPROF topics.
--Glenn
1. NM KSAM is being augmented with a "KSAM64" file type, using 64-bit
pointers internally (vs. the current 32-bit ptrs) to allow a larger
file. Usage should be essentially transparent, except for specifying
the new filecode when building the file.
I didn't think of this at the time, but I wonder what COBOL will do
when creating a new indexed file using only standard COBOL syntax.
I assume this will continue to create the 32-bit NM KSAM file, but
of course I could be mistaken.
2. Jeff Vance alluded to working on user-defined functions in the CI.
While the multiple-entry-points trick kinda-sorta simulates this,
true functions would be a VERY helpful addition! Don't hold your
breath, but keep your fingers crossed! :)
3. While no mention of a "Windows-type" interface was made at SIGMPE,
it was brought up at the management round table. Basically, HP is
taking a "wait and see" approach. Nick Demos pointed out how
important it is for HP to take a stand on this so that its customers
aren't developing in different directions.
On a related note, Gavin noted at SIGJAVA that IBM has a "product"
called (IIRC) Remove AWT which is freely downloadable from IBM's
web site.
Remember that AWT (Abstract Windowing Toolkit) is what Java uses
for platform-independent windowing (the newer Swing sits on top of
AWT). As I understand it, Remote AWT redirects Java AWT calls on a
host to AWT calls on client. Thus, even though we think of 3000 apps
as void of graphics, this allows for a GUI with a look-and-feel that's
native to the client. IMHO, this has TREMENDOUS possibilities.
I just wish that HP would take a more active stance on this topic.
4. Speaking of SIGJAVA, some comments were especially interesting:
a. It only takes about ONE WEEK for HP to implement a new release
of Java on the 3000. (Of course, there's still integration
testing, but still....)
b. While Java has been a quickly-evolving language (even in the
short time it has been out, there are some features that have
since been deprecated), it is entering a period of "feature
stability." No new features are anticipated for quite awhile.
(18 months? 2 years? I forgot.)
If the rapid change in the language definition has been your
reason for waiting to explore Java, well, wait no more!
c. Both Gavin and Mike Yawn mentioned they feared they had "scared
people off" by setting Java performance expectations low.
However, knowing that performance will continue to improve,
that should not be enough to stop people from getting a
feel for the language!
d. Speaking of performance, it is *highly* recommended that people
upgrade from 1.1.5 (or lower) to 1.1.7 . There are some pretty
important resource issues that are addressed by 1.1.7 (clever me,
I forgot what they are).
Note that 1.1.5 is what comes bundled with MPE/iX 6.0 .
e. Speaking of MPE/iX 6.0, note that while Java is present,
it is *NOT* installed by default! Apparently, they were
mostly concerned about disc space. When installed, it
takes about 100 MB.
Installation should be easy, but you have to do it explicitly.
Look for a job called something like JINSTJDK.INSTALL.JAVA .
f. At least one attendee mentioned the "paradigm shift" that it
took to understand the language, and object-oriented programming
(OOP) in general. While I know it has been described as such in
the literature, I can say only that such has not been my experience.
Personally, I find OOP much more natural than classical programming,
though certainly I still have much to learn.
(The big shift for me, and one that still requires a conscious
effort, is when writing either parsers or event-driven programs).
5. Debugging under Java looks interesting. Gavin gave the example
of Symantec's Visual Cafe 3, of which there are three versions:
standard ($100), pro ($300), and database ($1000). The $300 version
lets you do remote debugging; the cheap version does not.
As I understand it, on the 3000 side you start the app in a way
that says "wait for me before you do anything." On the client side
you start this remote debugging session. From that point on, the
client controls the host. You can single-step the code, display
variables, and do all kinds of wacky things.
Personally, I just don't like debuggers; they have mostly served
to distract me from understanding the code. With objects, though,
such a debugging tool may well be of greater importance.
6. Under the heading of "Don't try this at home (or work)," the
POSIX-porting seminar noted that if you run Qedit from within
the shell, then exit -- *suspending* Qedit -- the session hangs.
Bummer.
Personally, I experience the greatest productivity by staying
inside Qedit all day. This gives me a wonderfully integrated
environment (MPE, MPEX, Qedit, including keystroke-saving spoolfile
commands), with the lone exception of the POSIX shell.
Generally, I try to invoke the POSIX commands via HPBIN.SYS from
Qedit's command line, but sometimes this is just too much hassle.
I can see the advantage of invoking Qedit from the POSIX shell
and still living inside Qedit all day, going back to the shell
(suspending Qedit) only when needed. This could be problematic
if I need newly-set variables, though, so maybe there really is
no "perfect solution" to this.
7. The POSIX-porting seminar also noted the existence of CVS
(Concurrent Versioning System) on the 3000. This is built on
top of RCS (Revision Control System), and is a way of tracking
changes to source files automagically. Mark Klein ported it
as part of the GNU C++ compiler. IIRC, it is installed with
the "GNUCORE" files.
The big advantage to CVS is, as its names implies, concurrency.
That is, even though user Jack has KEYCODE.SOURCE checked out
for modification, user Jill can do this as well. CVS assists
with merging any changes.
The other big deal is that there is distinct provision for
vendor versions as well as user versions.
/
vendor v1.1
version /
/
v1.01
/
/___a__b___c__
user version
Below is an example of what COULD have happened when porting Java.
(No doubt actual events were significantly different.)
HP starts with version 1.01 of the product, and introduces it to CVS.
HP makes several mods to the product, shown here as releases 'a' and
'b'. When Java 1.1 comes out, it is imported into CVS (coincidentally
via the 'cvs import' command). At this point, CVS can tell what
changed between Java 1.01 and 1.1, *and* what changes were made
to Java 1.01 by the user. Using this knowledge, CVS can help to
merge the "official" changes in with the user's changes.
8. Speaking of development environments, many people (Gavin, Duane,
Cortlandt, Michael Hensley) commented on what a tremendous benefit
it is to have colour syntax highlighting available. While some
people achieve this by downloading files to the local machine,
this addressed more seamlessly by the emerging client/server-type
editors. Some examples include Whisper Programmer's Studio,
Robelle's Qedit for Windows, and PSG's Facade. (Qedit for Windows
doesn't have it yet, but it's coming, along with many other things.)
I think it was Cortlandt who mentioned spotting a long-standing bug
almost instantly, since the code (IIRC) was coloured as a comment.
Be aware, however, that there are trade-offs. For example,
Qedit for Windows does not have a command line, and it does
not support compiling (like the extremely-useful :COBERR UDC).
Much is coming; it just takes time.
Duane showed a few interesting features from the Whisper editor.
For example, it does support compiling; it shows the errors in
the bottom "frame" of the window, and clicking on an error
highlights the line in question. Also, if I understood the
screenshot correctly, it supports viewing the COBOL source in
an "outline" view, like when viewing a directory in Windows Explorer
(or viewing by anything-besides-icon on the Mac). COBOL paragraph
names and '01 levels' take the place of a directory, so expanding
a name means revealing the source therein.
Personally, I think this last is a great feature. Hopefully it
supports sections as well, so that expanding a section means
showing all paragraph names within that section. More importantly,
it should mean that collapsing the section also hides all that code.
This would certainly provide motivation to add section names so that,
say, all database-access routines are in a single section and can be
kept out of sight.
9. A recent paper on Jazz is on the tentatively-titled MPE/iX 6.1
enhancements. I haven't looked at that file, but Jeff handed
out a printed copy. Among other things, it mentions a new variable
called HPJULIAN -- ignore it. After much discussion, it was deemed
too confusing at this point, so it is being dropped for now. If a
more clearly-defined need arises, Jeff would be more than happy to
take another look at it.
10. One of the system enhancements in progress is increasing the size
of the Data Segment Table (DST). I remember bumping against this
in 1984, and I'm sure this is not the first increase since then.
Presumably, CSY has isolated this code as best they can since no
doubt this will not be the last need for DST expansion.
11. Lastly, and perhaps of greatest significance, Winston Prather
noted at the management round table that he is open to a type of
"open source" model for enhancing "stable" products. Mark Bixby
noted as an example that since he has so much time on his hands ;)
that he would consider adding support for HFS filenames to EDITOR.
IIRC, Mr. Prather would like to handle this on a case-by-case
basis right now. Also, it was pretty clear that he's not keen
on doing this for MPE itself, including MPE/V. I can't say that
I blame him.
The end (?). ;)
|
