|
Hi Michael,
<snip>
I've seen these posts, and I realize I'm speaking out of ignorance,
but why is this a goal? Convenience? Just because it can be done?
Would you perform testing out of this development environment? Would
there be additional user testing since they obviously won't be using
WSDCi to run programs.
Or would this goal be purely for development, and not for the other
parts of the system life cycle?
Just curious...
</snip>
That's a good question, and I'm sure I'm just turning over very old ground
here. :-)
This is just for development. I understand that testing a RPG screen-based
interactive program is going to require a 5250 session for testing, just as
I understand that testing a RPG HTTP server program is going to require
using Firefox/IE for testing. However, there are two scenarios where I would
not want to leave WDSCi to perform a task:
1)To navigate the IFS and work with the documents there.
Consider developing a RPG program which writes xml data to a folder in the
IFS. In the good old days, fFor me to test for well-formedness of a large
xml doc using EDTF was not an option, so I used to start up DOS, ftp to the
iSeries, "get" the xml doc onto my desktop and then open it in Firefox/IE.
Now I just use the QSHELL client in WDSCi and right-click the xml doc and
open with the system Editor. Job done! I can do this in the QSHELL client, I
was just curious about whether there was a QP2TERM-like equivalent.
2) To examine the properties of an object. For example checking the
signature of a service program or the format level identifier of a database
file.
We have the Command Language on the iSeries but as far as I can see there is
no WDSCi port of the DSP commands. That is a rather strange turn of events.
Of course, I may be off the mark here but I can't seem to find an equivalent
of DSPFD, DSPPGM, DSPSRVPGM, or DSPPGMREF in WDSCi. So if I test a program
and get a level-check I have to sign onto the iSeries to check the program
references and the file format level identifier.
All of the above could be derive purely from my ignorance of the WDSCi
product, and hopefully you guys on the list will educate me of the ways of
WDSCi. I am eager to stay in WDSCi as I believe it is a better development
environment than PDM. But (there's always a but) the simple fact that there
is a command line at the foot of every PDM screen means it kicks WDSCi's ass
regarding an integrated ability to access system/object information.
I hope this all makes sense
Cheers
Larry Ducie
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.