RE: Calling a program without knowing the parms

["Njal Fisketjon" <n.f@xxxxxxx>]

John Ross wrote:

> Thanks.  Yes batch jobs, different parameter list.
> 
> Sure I can say what I am working on.  A week or so ago someone wanted to 
> know about Socket programs and some else wanted to know about calling a 
> program from VB. I was interested in both of those so I started looking 
> into it. I had a book (TCP something from midrange computing) with a good 
> example of a sockets program and even how to use it with visual 
> basic. But 
> it requires you to write a second sockets program for every program you 
> want to run. So If I want to get the serial number of the AS/400 
> I have to 
> copy and paste into a program the socket logic then add the logic to get 
> the serial number and pass it back. Then if some other time I want the 
> description of the user profile, another copy and paste socket 
> program. It 
> get worse when you already have a program to do what you want on 
> the AS/400 
> (say pass an item number in and get description, quantity on hand  and 
> quantity on order) that is called from an AS/400 program and now you want 
> to call it from a PC program. Now you have to copy paste socket 
> program to 
> call the already written program and pass the parameter values 
> back to the 
> PC program.  I would just like a way to write the one socket program and 
> pass it in the program the parms and then send pack the parms. Even if on 
> the PC I had to format it like
> call iteminfo Parm('Item1' ' ' ' ' ' ')     which looks like it 
> would work 
> with qcmdexec  but no parms back from QCMDEXEC.  I am willing to put the 
> x'00000f' in on the PC for numeric packed fields. I guess I am willing to 
> even dig through the joblog if qcmdexec (or something else) would 
> write out 
> the out parms there.
> 
> Hope that was not to long and gives you an ideal of what I want to do.
> 

Using Client Access API's for DPC (Distributed Program Call) you could achieve
this, but I don't think you will reach break-even (work-wise) before using your
program to call a *lot* of different AS/400 programs.

Example DPC usage in VB:

Const CWBRC_INOUT = 3
Const CWBRC_TEXT_CONVERT = 48

Private Declare Function cwbRC_AddParm Lib "CWBRC" (ByVal program As Long, _
  ByVal typeParameter As Integer, ByVal Length As Long, parameter As Byte) As 
Integer

Private Declare Function cwbRC_CreatePgm Lib "CWBRC" (ByVal programName As 
String, _
  ByVal libraryName As String, program As Long) As Integer

Private QWCRSVAL As Long

  Dim rc As Integer
  
  rc = cwbRC_CreatePgm("QWCRSVAL  ", "*LIBL     ", QWCRSVAL)
  rc = cwbRC_AddParm(QWCRSVAL, CWBRC_INOUT, lSysValLength, bytSysVal(0))
  rc = cwbRC_AddParm(QWCRSVAL, CWBRC_INOUT, lSysValLenLength, bytSysValLen(0))
  rc = cwbRC_AddParm(QWCRSVAL, CWBRC_INOUT, lNbrSysValLength, bytNbrSysVal(0))
  rc = cwbRC_AddParm(QWCRSVAL, CWBRC_INOUT + CWBRC_TEXT_CONVERT, 
lSysValNamesLength, bytSysValNames(0))
  rc = cwbRC_AddParm(QWCRSVAL, CWBRC_INOUT, lErrorLength, bytError(0))


I use DPC a lot, but I encapsulate each call to an AS/400 program in a class, 
where
the CreatePgm & AddParms are in the Class_Initialize routine and the DeletePgm 
is in
the Class_Terminate routine.

Usually I create a wrapper program on the AS/400 so that I can pass all 
parameters using
character/zoned fields. I try to use 3 standard parameters (Parms 128, Header 
128, Data *)
where header is used to return length of the returned "structure(s)" and number 
of "records".
This way I can add fields to the returned structures without breaking the "old" 
versions
of the client program.

Using a VB class let's me structure the data retrieved in a way that suit's the 
data, which
I think makes programming and maintaining the PC application a lot easier.


+---
| 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
+---