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



Adrienne:

I think you have most answers already, so I'll stick to just a couple points.

First...

>  I
>would rather execute the commands from the COBOL program rather that
>calling CL as I do believe I read that the COBOL option would be more
>efficient.

I'm pretty sure that it would be more 'efficient' to call a bound ILE CL 
procedure, but that's in terms of machine efficiency. There _might_ be 
maintenance efficiencies that make it better to execute commands in COBOL via 
API, but there's no way we can know that in your case yet. It's rare that I've 
seen a bound procedure to be less efficient either way.

Note that this would be a "bound ILE CL module", not a call to a separate CL 
program even though that's probably still more machine efficient than using a 
command API.

Understand that OS/400 CL can be _compiled_ into callable programs and 
procedures, very much like COBOL, C and RPG. The languages can all bind to each 
others' modules and call in either direction. For CL, that's the difference 
between an interpreted command executed via API and a compiled command 
statement.

Other than that, it would be nice if you could trim unnecessary parts from 
replies to the list. By replying and including an entire digest -- and then 
having others reply and also include the entire digest -- the items get to be a 
real mess, both in the digests that are e-mailed out and in the archives.

And as a more general comment, for some reason, a lot of people are starting to 
keep their e-mail clients from marking included text. That makes at extremely 
difficult to track where one message ends and the next begins in a digest.

Anyway, it seems that almost everything you need can be done. The most common 
problem you'll find will probably just be finding a good way to do it. And 
that's what this list is for.

Tom Liotta

cobol400-l-request@xxxxxxxxxxxx wrote:

>   8.  RE: COBOL400-L Digest, Vol 3, Issue 103 (Adrienne McConnon)
>
>I must say I am thrilled I got some responses.   I did a little more
>digging on the iSeries and also found some information on functions -
>but I am not sure these are doable in COBOl?  Anybody know?
>
>As far as the HP intrinsics go, I will need to convert to iSeries the
>following:
>
>1.  PAUSE - which will suspend processing for a specified number of
>seconds.  Found this as a function on iSeries - but it looked like maybe
>it was C and I could not find any confirmation that this function is
>doable in COBOL.
>2.  HPCICOMMAND - Is basically an intrinsic that allows you to execute a
>command line type command - I need to stream a job and copy a file,
>manipulate JOBQ and initiate FTP and execute some FTP commands - which I
>think I can do by calling a CL (please correct me if I am wrong).  I
>would rather execute the commands from the COBOL program rather that
>calling CL as I do believe I read that the COBOL option would be more
>efficient.
>3.   'SETJCW' - Sets bits in the system job control word (JCW).
>4.  FRENAME -  NM and CM callable.  Renames an open disk file (and its
>lockword, if applicable). The file being renamed must be either: A new
>file, An old file (permanent or temporary), opened for exclusive access
>with the exclusive option of the HPFOPEN/FOPEN intrinsics, and with
>security provisions allowing write access.
>5.  Plus some error message intrinsics - found a lot about error
>handling on iSeries - still trying to decipeher.
>6.  Also others - but I think if I can get a good grasp of a few of
>these the others will fall into place.


As an Amazon Associate we earn from qualifying purchases.

This thread ...


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.