Re: Db2dclgn Indicator variables
- From: "Frank Swarbrick" <Frank.Swarbrick@xxxxxxxxxxxxxx>
- Date: Fri, 19 Jan 2007 19:04:07 -0700
Dan van Ginhoven<danfan46@xxxxxxxxxxx> 01/19/07 1:48 PM >>>
Hi!
I'm using db2 UDV v9.1 and MF Cobol Net Express v 5.
db2dclgn generates cobol descriptions for a table.
Like table Employee in the sample database.
01 EMPLOYEE.
05 EMPNO PIC X(6).
05 FIRSTNME.
49 LEN PIC S9(4) COMP-5.
49 DAT PIC X(12).
05 MIDINIT PIC X(1).
05 LASTNAME.
49 LEN PIC S9(4) COMP-5.
49 DAT PIC X(15).
05 WORKDEPT PIC X(3).
05 PHONENO PIC X(4).
05 HIREDATE PIC X(10).
05 JOB PIC X(8).
05 EDLEVEL PIC S9(4) COMP-5.
05 SEX PIC X(1).
05 BIRTHDATE PIC X(10).
05 SALARY PIC S9(7)V9(2) COMP-3.
05 BONUS PIC S9(7)V9(2) COMP-3.
05 COMM PIC S9(7)V9(2) COMP-3.
01 IND-TAB-EMPLOYEE.
05 IND-EMPLOYEE PIC S9(4) COMP-5 OCCURS 14 TIMES.
1. Why doesn't IBM provide a prefix for varchar LEN and DAT fields ?
Now I have to refer to "DAT in FIRSTNME in EMP" which is bit
tedious.
Any workaround ?
(The internal table description generator in Netexpress generates
MIDINIT-DAT and MIDINIT-LEN)
2. How do I use the Indicator table?other
The preproceesor does not allow me to use
FETCH ..... :EMP.MIDINIT INDICATOR :IND-EMPLOYEE(3) or any
construct that I've tried.
Is the indicator table meaningful in some other language / compiler
or what ?
If I recall correctly from trying this just a few weeks ago, you cannot use
the individual indicated occurances directly. The only time you can use
them with your working storage described above is if you do a "group fetch".
EG:
FETCH * FROM EMPLOYEE INTO :EMPLOYEE:IND-TAB-EMPLOYEE
If you only want to fetch certain columns you have to declare each indicator
individually, ie:
01 IND-EMPLOYEE-1 PIC S9(4) COMP-5.
01 IND-EMPLOYEE-2 PIC S9(4) COMP-5.
01 IND-EMPLOYEE-3 PIC S9(4) COMP-5.
01 IND-EMPLOYEE-4 PIC S9(4) COMP-5.
01 IND-EMPLOYEE-5 PIC S9(4) COMP-5.
And then do a fetch as follows:
FETCH MIDINIT FROM EMPLOYEE INTO :MIDINIT:IND-EMPLOYEE-1
Pain in the ***? Yes indeed! As much as COBOL was the main language when
DB2 was starting out, they two don't work together in a very friendly matter
much of the time.
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
.
- Follow-Ups:
- Re: Db2dclgn Indicator variables
- From: LX-i
- Re: Db2dclgn Indicator variables
- From: Michael Russell
- Re: Db2dclgn Indicator variables
- From: Dan van Ginhoven
- Re: Db2dclgn Indicator variables
- References:
- Db2dclgn Indicator variables
- From: Dan van Ginhoven
- Db2dclgn Indicator variables
- Prev by Date: Re: Db2dclgn Indicator variables
- Next by Date: Re: Db2dclgn Indicator variables
- Previous by thread: Re: Db2dclgn Indicator variables
- Next by thread: Re: Db2dclgn Indicator variables
- Index(es):