|
Steve Richter wrote: on a windows pc this is also not an issue because pgms dont call other pgms like they do on the 400. The pgm call equivalent in Windows is a call to a function in a dll. Quite right. But, of course, a DLL is very analogous to our *SRVPGM. So Larry, does the C pgm make a copy of the string before it null terminates it? I would expect it does. Remember that to follow the C conventions, the "first" parameter (argv[0] in C terms) is the name of the program, so a copy is likely anyway since the second parm on main is an array of arrays. This would be most unlikely to match the original OS/400 calling conventions, which is a series of strings and, possibly, even decimal numbers And weather(?) a copy is made or not, does the C pgm know the size of the data passed? I should have not jumped in while still jet-lagged. I'm having trouble remembering my name much less all these details today. Still, this is why I think this is part of why I mentioned (in passing) the command processor. It seems to understand some of these things. I would suggest some simple experiments, especially with a series of calls from the same command line (so that it is likely the previous data would be used at least before the C program was invoked). A series of calls like: CALL TEST '12345' '212345' CALL TEST '124' '214' CALL TEST '123 45' '2123 46' and see what happens to an ordinary "printf" of the first two parameters. Do the same thing wrappering TEST in a command that describes a fixed length string for each parameter. Try bigger string to smaller and back again would be the thing I would try. I presume that using CALL means someone somehow infers the size from the distance between quotes, but how that is copied is not clear to me (not without coding it up myself to remind myself of all these little details). As I've said, the command line processing may be a bit different, if for no other reason that I believe if you describe the parameters sufficiently well, that incoming strings can get padded with space characters and so on, which eliminates a few of the more odd-ball things that have happened to me now and then when I use a series of ordinary CALL statements carelessly. But, my memory fails me on exactly what happens. Also, do as400 C pgms return values to the caller? I believe *SRVPGMs would and could return whatever they are defined to return. The implications of returning character strings to compiled ILE CL is a bit beyond me today (I recall there are some interesting conventions on the CL side of it, but I don't use them, so I don't know). This should be documented in the various manuals, however. The return 0 or return n statement for some 32 bit integer n would be, I think, what main (by standard convention) returns to OS/400 and this should be have "normally." Normally, I would code these up and put in the results myself, but I'm not up to that today. Try a few experiments. . . Larry W. Loen - Senior Java and iSeries Performance Analyst Dept HP4, Rochester MN Speaking on his own. . . +--- | This is the MI Programmers Mailing List! | To submit a new message, send your mail to MI400@midrange.com. | To subscribe to this list send email to MI400-SUB@midrange.com. | To unsubscribe from this list send email to MI400-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: dr2@cssas400.com +---
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.