Re: Db2dclgn Indicator variables

Yes..., which is what I do not like. You have to explicitly set the length
field somehow. Like:

MOVE FIRSTNAME-INPUT TO D OF FIRSTNME
COMPUTE L OF FIRSTNME = FUNCTION LENGTH(D OF FIRSTNME)
CALL 'VARCHAR' USING FIRSTNME

MOVE LASTNAME-INPUT TO D OF LASTNAME
COMPUTE L OF LASTNAME = FUNCTION LENGTH(D OF LASTNAME)
CALL 'VARCHAR' USING LASTNAME

EXEC SQL
INSERT INTO EMPLOYEE (FIRSTNME, LASTNAME)
VALUES (:FIRSTNME, :LASTNAME)
END-EXEC

'VARCHAR' is a subroutine that sets the length part of a "VARCHAR" variable
to the number of characters in the data part, sans trailing spaces.
IDENTIFICATION DIVISION.
PROGRAM-ID. VARCHAR.
DATA DIVISION.
WORKING-STORAGE SECTION.
77 TSP PIC S9(4) COMP.
LINKAGE SECTION.
01 FIELD-VAR.
05 FIELD-LEN PIC S9(4) COMP.
05 FIELD-VAL.
10 PIC X OCCURS 1 TO 32767
DEPENDING ON FIELD-LEN.
PROCEDURE DIVISION USING FIELD-VAR.
MOVE ZERO TO TSP
INSPECT FUNCTION REVERSE(FIELD-VAL)
TALLYING TSP FOR LEADING SPACES
SUBTRACT TSP FROM FIELD-LEN
EXIT PROGRAM.
END PROGRAM VARCHAR.

Anyway, wouldn't it be nicer to say:
MOVE FUNCTION TRIM(FIRSTNAME-INPUT) TO FIRSTNME
MOVE FUNCTION TRIM(LASTNAME-INPUT) TO LASTNAME
EXEC SQL
INSERT INTO EMPLOYEE (FIRSTNME, LASTNAME)
VALUES (:FIRSTNME, :LASTNAME)
END-EXEC

That's all I'm getting at.

FWIW, we're only now just looking at using DB2, so I don't have much real
life experience. But rather than using the COBOL "varchar" fields (level 49
stuff) I'm considering just using regular character string fields (PIC
X(255) or whatever) and using the DB2 RTRIM function like this:
MOVE FIRSTNAME-INPUT TO FIRSTNME
MOVE LASTNAME-INPUT TO LASTNAME
EXEC SQL
INSERT INTO EMPLOYEE (FIRSTNME, LASTNAME)
VALUES (RTRIM(:FIRSTNME), RTRIM(:LASTNAME))
END-EXEC

Probably not as efficient, because you end up sending the entire maximum
length of characters to the database, but it looks OK to me. Of course I
reserve the right to change my mind! :-)

Frank

---
Frank Swarbrick
Senior Developer/Analyst - Mainframe Applications
FirstBank Data Corporation - Lakewood, CO USA

Michael Russell<Michael.Russell@xxxxxxx> 01/21/07 2:39 AM >>>
top post.

Aren't level-49s there for lengths of varchars?

Regards

Michael

Frank Swarbrick wrote:

For instance, I'd love to see a COBOL that supports the ANY LENGTH
PREFIXED
clause for a much more natural VARCHAR. Just think of it:

01 EMPLOYEE.
05 EMPNO PIC X(6).
05 FIRSTNME PIC X ANY LENGTH
LIMIT IS 12
PREFIXED BY BINARY-SHORT.
05 MIDINIT PIC X(1).
05 LASTNAME PIC X ANY LENGTH
LIMIT IS 15
PREFIXED BY BINARY-SHORT.
05 WORKDEPT PIC X(3).

EXEC SQL
FETCH EMPNO, FIRSTNME, MIDINIT, LASTNAME, WORKDEPT
FROM EMPLOYEE
INTO :EMPNO, :FIRSTNME, :MIDINIT, :LASTNAME, :WORKDEPT
END-EXEC

MOVE 'NEWNAME' INTO LASTNAME
EXEC SQL
UPDATE EMPLOYEE
SET LASTNAME = :LASTNAME
WHERE CURRENT OF CURSOR
END-EXEC
No fiddling around with INSPECT ... in order to get the length of the
field
(sans trailing spaces), no need for the SQL RTRIM function, or any other
annoying workarounds.

Of course this almost seems a pipe dream. Even if, say, Micro Focus
implemented this feature, we'd still have to have IBM implement support
for
it into the precompiler. (Or does MF use it's own pre-compiler?)

I'd also love to see some kind of COBOL support for "null" values. Even
with the proposed COBOL 2008 features (of which ANY LENGTH PREFIXED is
one)
I don't think there's anyway way to specify a field (other than an actual
pointer, of course), as having a value of "NULL". But I'd love to see it!

I know that C# has support for this. Never seen any other language with
it,
though.

Back to the real world, though...
As someone else said, you can just use DAT OF LASTNAME (or DAT IN
LASTNAME)
to uniquely qualify that field. (Again, I personally would love to use
LASTNAME.DAT).

Also, there is of course nothing that says you can't edit the output from
db2dclgn prior to using it. I personally would do that unless perhaps I
had
several hundred columns and no time to fiddle around editing them. You
only
have to do it once. As you add new fields you just put them into the
copybook by hand, maybe using db2dclgn to guide you to the proper PICTURE
and USAGE.

Hope this helps, and is accurate. As I said, I could be wrong about the
IND
thing, but I believe I am correct.

Frank


---
Frank Swarbrick
Senior Developer/Analyst - Mainframe Applications
FirstBank Data Corporation - Lakewood, CO USA


.