I see Jon has given you some answers. I will add my own comments:
The ILE COBOL Programmer's Guide (V5R4) has a section on mapping
COBOL data types to RPG data types. See page 318 in the PDF.
On 26/02/2008, at 5:30 AM, Aaron Bartell wrote:
I didn't know if COBOL would ever enter my life again, but it has
and I am
doing some wheel spinning. I am working with a shop that is on the
iSeries
and has zero RPG coders so I am trying to span the gap and
understand some
basic ILE syntax priciples in the COBOL environment.
Below I have contructed a very busy sub procedure that takes on a
variety of
parameter passing features. I have been reading the Infocenter COBOL
manuals but the going is slow and I am wondering if somebody could
give me a
kick start and convert it into COBOL??
Basically I need to know:
1) How to build proc1 into a COBOL prototype that could be /COPY'd
into a
COBOL program
No prototyping as such but you can use the SPECIAL-NAMES paragraph to
define certain aspects of the interface. You can specify the linkage
type is a procedure (rather than program) and you can specify which,
if any, parameters need an operational descriptor. You will need an
operation descriptor passed if you rely on RPG %PARMS. For example:
linkage procedure for "FBNGETDAY" using all described
I put all these definitions in one or more copy members and then add
the following to the COBOL source:
ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
SPECIAL-NAMES.
LINKAGE SYS FOR "CEEHDLR"
COPY FBNDATE OF CBLLEINC.
COPY FBNMSG OF CBLLEINC.
.
NOTE 1: LINKAGE SYS is necessary is you want to invoke CEE APIs.
NOTE 2: The line below the second copy statement contains a full stop
(or period to you lot) and is necessary to properly terminate the
SPECIAL-NAMES paragraph. It may get removed in transit (although that
should only happen if it's in the first position of the line).
I find this easier than using CALL PROCEDURE throughout the COBOL code.
NOTE 3: COBOL mono-cases procedure calls unless you over-ride that
behaviour. Specify NOMONOPRC on the PROCESS statement (like an H-spec
for compiler options) or on the CRTCBLMOD/CRTBNDCBL OPTION keyword.
I realise you are linking to RPG and the default is for RPG to export
mono-cased procedure names but it does not have to do that.
2) How to build a data structure and then reference it using something
similar to our LIKEDS (I saw COBOL has the LIKE keyword and I have
been
playing around with that).
Most program variables go in the WORKING-STORAGE Section. Data
structures are built using level numbers to identify the nesting.
Level 01 would be the DS itself, level 05 would be the first group of
sub-fields, level 10 would be sub-fields that overlay one or more sub-
fields at level 05, etc. You can set you own level numbers (between 1
and 49) as you see fit but there are some that have special meaning
to COBOL such as level 66, 77, or 88. For example (from the manual):
01 EMPLOYEE-RECORD.
05 EMPLOYEE-NAME.
10 FIRST PICTURE X(10).
10 LAST PICTURE X(10).
05 EMPLOYEE-ADDRESS.
10 STREET PICTURE X(10).
10 CITY PICTURE X(10).
The source indenting is simply a visual cue (like RPG IV) and has no
bearing on the structure.
No LIKEDS support.
COBOL's LIKE clause is similar to RPG's but does not allow the length
to be changed.
COBOL's REDEFINES clause is similar to RPG's OVERLAY keyword.
3) Show an example of calling this sub procedure from a mainline.
COBOL supports passing parameters BY REFERENCE (the default), BY
VALUE, and BY CONTENT which is similar to RPG's CONST without the
automagic data type conversions.
CALL PROCEDURE PROC1 USING BY CONTENT p1 p2 BY VALUE p3 BY VALUE p4
p5 p6 GIVING some-result.
or
CALL PROCEDURE PROC1 USING BY CONTENT p1 p2 BY VALUE p3 BY VALUE p4
p5 p6 p7 GIVING some-result.
or
CALL PROCEDURE PROC1 USING BY CONTENT p1 p2 BY VALUE p3 BY VALUE p4
p5 p6 p7 p8 GIVING some-result.
If you want to omit p2 then use the OMITTED keyword.
CALL PROCEDURE PROC1 USING BY CONTENT p1 OMITTED BY VALUE p3 BY VALUE
p4 p5 p6 p7 GIVING some-result.
NOTE: Not specifying BY CONTENT on p1 will have no effect on the call
except that the called procedure is addressing the caller's storage
directly.
4) Show an example of defining/coding a local sub procedure.
No local procedure support. Can use nested programs or separate
modules (like V3R1 RPG). Can have named sections of code and pass
control using PERFORM--behaves like subroutines in RPG.
D proc1 pr 3 0
D pParm1 10a const
D pParm2 15P 0 value options(*omit)
D pParm3 z value
D pParm4 128a value varying
D pParm5 n value
D pParm6 like(fld1)
D pParm7 likeds(ds1) options
(*nopass)
D pParm8 * procptr value options
(*nopass)
The CALL PROCEDURE statement above will require appropriately defined
variables.
Because you are using *NOPASS you must be relying on %PARMS therefore
you will require a minimal operational descriptor to be passed. I
don't recall whether COBOL passes a minimal descriptor like RPG but I
generally need full descriptors:
So:
ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
SPECIAL_NAMES.
linkage procedure for "PROC1" using all described.
(You could probably get away with using 1 described if all you need
is %PARMS)
Variables and parameters would be something like:
DATA DIVISION.
WORKING-STORAGE SECTION.
01 fld1 pic x(10).
01 ds1.
05 fld1.
10 fld1-len pic s9(4) COMP-4.
10 fld1-data pic x(1024).
05 fld2 pic x(10).
05 fld3 pic s9(9) comp-4.
05 fld4.
10 fld4-len pic s9(4) COMP-4.
10 fld4-data pic x(30).
01 p1 pic x(10).
01 p2 pic S9(15) COMP-3.
01 p3 format of timestamp.
01 p4.
05 p4-len pic S9(4) COMP-4.
05 p4-data pic x(128).
01 p5 pic X(1).
88 ind-off VALUE "0".
88 ind-on VALUE "1".
01 p6 like fld1.
01 p7 like ds1.
01 p8 procedure-pointer.
NOTE: LIKE on ds1 declares a FIELD the same length as DS1, not a data
structure.
D fld1 s 10a
01 fld1 pic X(10).
D ds1 ds qualified inz
D fld1 1024a varying
D fld2 10a
D fld3 10i 0
D fld4 30a varying
Jon already showed you this. All COBOL structures are implicitly
QUALIFIED. You have to do the hard work related to varying fields but
COBOL provides intrinsic functions that can help. Still not a good
choice for cross-language support.
Makes me with they had a "COBOL for RPG programmers" book :-)
Interoperation is described reasonably well in the COBOL Programmers
Guide.
Hmm, that turned out to be more detailed than I intended.
Thanks in advance,
Aaron Bartell
http://mowyourlawn.com
--
This is the RPG programming on the AS400 / iSeries (RPG400-L)
mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.
Regards,
Simon Coulter.
--------------------------------------------------------------------
FlyByNight Software OS/400, i5/OS Technical Specialists
http://www.flybynight.com.au/
Phone: +61 2 6657 8251 Mobile: +61 0411 091 400 /"\
Fax: +61 2 6657 8251 \ /
X
ASCII Ribbon campaign against HTML E-Mail / \
--------------------------------------------------------------------
midrange.com
