Re: Calling a program without knowing the parms

On Wed, 4 Jul 2001, John Ross wrote:
> 
> Ok, it is open source. I am not sure if it needs to be released with one of 
> the open source licenses or not. And if so which one. I want to do some 
> other open source projects so this will be a good place to start and work 
> out some of the kinks of handling open source projects.

There are two major licenses that I know of for open source.. the GPL and
the BSD license.   You might start by exploring the difference between
them.

Personally, I use the BSD license.  But don't ever ask "which is better?"
in open-source communities, because the "holy war" that results will go on
for weeks :)

> The only reason I said active X was because I am learning visual basic. I 
> read a book on C++ and one on Visual Basic and decided on Visual Basic, 
> because C++ seamed to hard, with pointers and memory leaks, etc.  I want to 
> learn C++ so I can work with Linux. I run two Linux Servers.

Actually, I'd recommend that you learn C first.   It's more widely used on
Unix-based platforms like Linux than C++ is, and it's also more similar to
RPG since C is also a procedural language.   C++ is an object-oriented
language that's based on C.

My opinion is... learn C.  Then Java... then C++ if you HAVE TO.  (You can
tell I'm not a huge fan of C++)


> I do not have much on the PC side, one module in Visual Basic that is 
> mostly hard coded to try to get this stuff to work.
> 
> If we need to move this to the open  source list or move offline or move it 
> to its own mailing list that is fine with me.

I'm sure we can discuss the RPG side of it here :)  But, if it helps, I
can set up a mailing list on my own server to discuss these things.  


> I looked at your pointer example in more detail in your other email. Let me 
> see if I understand a little more.
> We are always referring to an address in parmbuffer?

In that example, yes.  The idea is that all the parms are in the buffer,
and we need to pas the address of each parm individually when calling 
PgmNameVar.

> We do not care about the lengths because the program in PgmNameVar will 
> have the correct lengths?
> We just tell it where to start and make sure the values are correct?

Correct.   In fact, even if we did care about the lengths, it wouldn't do
us any good, since PgmNameVar will use it's own lengths, not ours :)

> A routine will have to be added for packed fields? Because it will not be 
> passed as packed because of the ASCII to EBCDIC translation. But some RPG 
> programs will expect packed parameters. No ideal how to do this.

Yeah, as part of the design you're going to have to make a decision about
how to pass these.  Since the packed data type doesn't even exist in VB,
you'll want the VB program to convert them to some neutral type for
sending over the socket, and then have the RPG program convert them to
packed (or whatever data type is appropriate)

> We will have to set this up to handle 255 parmoffset (in a do loop I hope)?
> 

Or whatever max # of parms you decide to support :)  The only reason I
suggest 255 is because I believe that's the max allowed by RPG.  I'm sure
you'll be able to find a way to use a loop for at least part of it :)

> No I have not tested it with a lot of users. Just me to try to get it 
> working and learning about sockets, so not even a production job yet.
> 
> I figure the connect will have the user id and password in it, it will do 
> the check, find a port and then the submit. No waiting on user id or 
> password. I understand one connection at a time, any delays and you delay 
> the jobs behind you.

I've given my opinions on this topic in a private E-mail to you...

> 
> I am up for making the PC side call format the parms, but thought it might 
> be confusing trying to tell type, size,  and value on the call each time. 
> But I am open to suggestions and change. And have not given the PC side 
> much thought yet as I am still working on how it can be done on the AS/400 
> side.
> 
> Thanks again for your help.
> John Ross
> 


+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---