I missed these web5250 threads just before Christmas as I had my head down
doing CGIDEV2 development. I am grateful to Nathan for telling me about
them.
I don't think that DSPF DDS is so very limiting. You can share a DSPF
between multiple programs and more than one program can write to the screen
at the same time. So, a request processing program (RPP) might call an
exit program, EXITA, which would WRITE a detail format for (say) data entry,
and return (leaving LR *OFF) to RPP which could EXFMT a header format. When
the user does something, unless it is a cancel, RPP calls EXITA again which
READs the detail format. EXITA could pass the data back to RPP which might
pass it to MAIN for updating a central database or EXITA might update a
record in a file, or send an email, etc.. All function keys, etc. could be
defined in the HEADER format and don't need to be redefined in the detail
formats in EXITA (or EXITB etc.). You can have mutiple header formats.
I have been doing this for over 20 years and it works very well with
excellent response times (below 0.05 seconds on a 170 in 5250 mode). In my
implementation, it is MAIN that calls the EXIT programs. You can even have
two DSPFs open at the same time on the same screen, but when I tried this, a
long time ago, reponse times were poor so I didn't take this any further.
Instead I put all my formats for all applications into one DSPF. This is
opened by RPP when a user signs on and remains open until he/she signs off,
however many times he switches applications (good for response times). All
applications use RPP but may switch between different EXIT programs.
I believe that there is an API that allows you to generate screen layouts
dynamically but I haven't tried this. By combining several formats on a
screen, you won't need a new format so often, but, If you do need a new
format, you add it to the single DSPF and recompile it. I put IGNORE
statements into my programs for formats that they do not need. MAIN does
not use a DSPF.
I suppose this process is helped by my using my own menu system. All my
menus are stored in my database and accessed by MAIN which controls business
logic and so which EXIT programs are called, which header and detail formats
are to be used, etc. This menu system has enormous flexibility - it can
have sub menus up to 1 billion levels deep (if I could think up what they
might do!) and the menus can be contextually based where the context might
be application, environment menus (e.g.Web) , functional menus
(i.e.different ones for add, delete, printing, etc.), user ID, job function
of user, department, location of user, operating language, entity type or
even individual entity - i.e. selecting different entities from the same
table could result in different lower level menus being displayed. It also
controls transaction boundaries for commitment control and very tight
security. RPP, MAIN and the exit programs are all written in ILE RPG
although the earlier versions were written before ILE came along.
I was using AS/400 WorkStation Gateway for the web and had modified the look
and functionality of the WSG screens. As that is no longer supported, I am
now redeveloping (at last!) using persistent CGIDEV2. With WSG, and now
with CGIDEV2, my aim has always been that just one set of code will support
both HTML and 5250 environments and that nothing had to be loaded onto the
client (apart from browser) I also wanted the shortest possible learning
curve and the best performance, so I have kept away from JAVA etc. Although
I have some way to go with CGIDEV2, I have got far enough to convince myself
that persistent CGIDEV2 will do what I want, even if I find stumbling blocks
along the way. It seems that with CGIDEV2 there is a facility roughly
equivalent to shared display files but I have not yet tried this. I have a
way round this problem if it does not. It also seems that there is a way of
allowing the equivalent of using two display files at the same time (i.e.
combining separate HTML source files). Although very early days, it seems
that response times with CGIDEV2 will be OK.
Rather than use "native" 5250 attributes, I insert 5250, HTML/JavaScript or
PCL5 codes into the datastream as appropriate. So when you see what appears
to be a 5250 subfile displayed, it is in fact one field of 800 characters
(or more) wrapping for ten (or more) lines which does not have 5250
attributes defined in DDS - these are inserted by my code. The data in the
false subfile can be put there by RPP or EXIT or both. This single format
can be used to display an unlimited number of apparently different
subfiles. I do use quite a few buffers within my code to facilitate this.
In both 5250 and HTML mode, I can have up to 356 characters in a line (if I
remember correctly). In 5250 mode, if the line is longer than 80
characters, F20 (window right) and F19 (window left) are automatically
enabled by RPP and a prompt is displayed. In update mode, I still use
separate formats with standard 5250 attirbues put there by DDS. It is
possible to combine records on one display line if required. There are
multiple exit points for added flexibility. Yet with all these facilities,
the learning curve works on a "need to know" basis so if you don't need to
use a facility, you don't need to learn about it.
The mechanism for inserting 5250 attributes, HTML, etc. can be used for
other environments - for instance it would be easy to generate XML. or even
a Word document (as long as I don't have to do the coding!).
This may seem very complex but it is very simple. The same code is used
both for development and operational environments and the main programs -
RPP, MAIN and the most frequently used EXIT program - total under 5Mb with
observability removed.
When considering the best way forward, we worry, quite correctly, about the
traffic being transmitted between servent and client. My WSG web pages,
without images, are typically 8k to 20k. This includes the Javascript to
modify WSG. With CGIDEV2, this won't be necessary so they might be smaller
but of course I may add functionality. At the 10k level, a page might
include 10 links, each with "ONMOUSOVER", "OndblClick", "OnClick" and
"onmouseout" and I don't consider this verbose. A 20k page might have 60
links each with "ONmouseover" etc. Some may consider that 20K is far too
large, but 60 links on one page is quite a large number. Transmission times
are not the only thing that affect response times. Opening and closing
files, calling programs, program paging, checking AS/400 security, etc. can
consume a lot of resource. I haven't checked the size of the PAG for many
years (I cannot even remember now how to do it in performance tools!) but,
although I know that it will have grown, my response times suggest that it
is not a problem.
I am trying in my new CGIDEV2 work to make a facility that could be also
used with non-ERROS applications. However, I don't see this as becoming a
magic wand. I think that anyone who wants to use it will have to make
changes to their applications but I don't think that these will be very
complex and I hope that the learning curve will be short.
Lots of good ideas have been put forward in these threads. It seems sad
that with the web now having been around for some years that these problems
have not been solved by IBM or others. We should be spending our time
solving user problems rather than getting involved in techncial minutiae
(even if this is what we enjoy most!). I am certainly trying to solve the
problem but I am just one person. We should somehow try and find a way of
working together - I suspect that none of us will get the right answer
working alone.
We could then move on to working on trying to keep our applications evolving
in time with the ever changing real world of the users.
Rob Dixon
www.erros.co.uk
2008/12/22 Aaron Bartell <aaronbartell@xxxxxxxxx>
>Would you consider DDS a moving target?
I do so little with DSPF DDS these days that I couldn't really say,
though
I would have to imagine that DSPF DDS gets very little attention from IBM
- am I wrong?
The rest of what you are saying I agree with. A lot of moving targets in
the end. The good thing is it seems the targets are always moving
forward, but the pace is so slow, and mistakes so many, that it doesn't
lend itself to meet the business needs AS400 shops have had since
realizing that our users wouldn't stand for green screens.
I know we have had these exact same conversations before on the midrange
lists, but I do feel that each time they occur, despite overlap from the
last thread, we are still making progress forward.
Now that Pete has posted the source for web5250 I hope to "pitch" it to a
client of mine as an alternative to their attempts at CGIDEV2 (which they
have been successful at, but the continuous pain and surprises are
keeping
their candle lit at both ends). Solutions like web5250 might not be the
end-all-solution but they can be a "good enough" stepping stone to get
people productive developing business applications vs. constantly trying
to figure out technology. I hope that they take me up on my idea so I
can
put some time into web5250 and submit my code changes back to the
community.
Aaron Bartell
http://mowyourlawn.com
Nathan Andelin wrote:
From: Aaron Bartell
HTML will forever be a moving target ...
Would you consider DDS a moving target?
I don't see HTML as much more of a moving target than DDS. That's one
reason I've chosen HTML, CSS, and JavaScript to build a UI for business
applications. It's ubiquitous, backed by standards, and can be home-grown,
which offers the most control.
But I kind-of get your drift. You seem to be generalizing, and stirring
the pot.
You can design your own UI using HTML, JavaScript, and CSS. Or you can go
with any number of rich UI tool-kits, each of which offers their own
component palette; all of which could be moving targets. Or you could go
with a tool that generates a rich UI from its own component palette and
templates. Or the browser could be used for little more than instantiating
applets, Flash, or Silverlight runtimes, where the UI would be defined by
those respective technologies.
I'm aware that a number of prominent UI frameworks are being paired with
prominent server technologies, and that big players are working to control
this space.
Fortunately, I'm past that, and not overly concerned about the multitude
of UI technologies that one can chose from.
My focus is application development. I don't envy you having to chose a
UI technology.
Of course it's best if ones application design offers enough separation
between UI and other logic, that change is less traumatic ;-)
Nathan.
--
This is the Web Enabling the AS400 / iSeries (WEB400) mailing list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/web400.
midrange.com
