× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Hi Larry

Interesting points - let me offer 2 possibilities

1. You don't necessarily need to use QShell to get at the IFS - there is and "IFS Files" segment of the conneciton in RSE - you can even make filters there, multiple paths are possible, and the files can be opened with any WDSC editor that is appropriate, I think.

2. I'm with you on the matter of various descriptive information - if you right = click any object in RSE and click on properties, you get basically some of DSPOBJD - but for files you hardly get any of the file description info - this seems a big hole to my thinking.

Now you can have a terminal session - and with Arcad's plugin it can be right there in WDSC - and then you can run STRRSESVR there and any interactive commands will use that session - then you can make object and member actions in RSE that will give you what you want. Maybe!!! It IS going to a green screen but completely within the confines of WDSC.

Hmmm!

Cheers
Vern

At 05:38 PM 12/1/2007, you wrote:

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 thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.