I didn't examine fully what the program is supposed to do, but I guess
it extracts
the member and library names from the DBRMs and builds JCL to do the
package BINDs for the DBRMs. I didn't even look at actual DBRMs and check
if the information regarding library names and members is indeed encoded in
Unicode. But the whole DBRM member which was readable in the ISPF editor
in the earlier releases of DB2 is encoded in Unicode since version x of DB2
(x maybe = 8), and I expect to see some Unicode handling in a program that
deals with DBRMs, so I guess that this program will not work with
today's DBRMs.
This is just a guess ... but the OP said the program was not compiled
for years,
so it seems to be old, and so I believed it was a good idea to make this
point ...
Kind regards
Bernd
Am 30.09.2012 15:58, schrieb John Gilmore:
Bernd's most recent post makes yet another important point, this one
crucial, about the inadequacies of the program being examined.
It was never well conceived qua PL/I procedure, and it is now obsolete.
It can perhaps be patched up; but my guess is that it should be
rewritten in PL/I, which is better at dealing with both UNICODE and
DB2 control blocks than, say, C.
--jg
On 9/30/12, Bernd Oppolzer <bernd.oppol...@t-online.de> wrote:
Like others already mentioned, to get rid of the syntax errors, you will
have to
add a declaration like
DCL P PTR;
and you should remove STR from the DCL ... BUILTIN;
But another idea or question:
the program IMO tries to read some DBRMs (DB2 data base request modules),
extract some information from there and construct BIND JCL to do BINDs on
some particular DB2 subsystems or environments.
Now my problem is:
the DBRMs have been converted in the recent DB2 versions from EBCDIC
to Unicode. So I believe this approach the program uses will not work
anymore,
because the program expects to find the information in the DBRMs in
EBCDIC code.
Please take a look at this, too.
Kind regards
Bernd
Am 29.09.2012 19:09, schrieb John Gilmore:
Mike Schwab wrote:
<begin extract>
DCL LLIB(10) CHAR(44) INIT(' ');
Could have 10 blank literals seperated by commas?
DCL DISP(20) FIXED BIN(15) INIT(0);
Could have 20 zero literals seperated by commas?
<end extract>
String and coded-arithmetic initializations are somewhat different.
Here, to initialize all of the elements of both arrays, write
declare llib(20) character(44) initial((20)(1)' ') ;
declare disp(10) fixed binary(15,0) initial((20)0) ;
The first has three components: an element-repetition factor, a
string-repetition factor, and a string value. Since padding on the
right with blanks occurs anyway in character strings it is not
strictly necessary to write it so: but a better, more explicit version
of the first declaration would be
declare llib(20) character(44) initial((20)(44)' ') ;
in which the initial specification is in effect: initialize each of
the 20 elements of this array with 44 instances of a single blank
concatenated together. Or again one could write,
declare llib(20) character(44)
initial((20)(1)' ') /*
44 blanks */ ;
But note that even here the string repetition factor must appear.
The code as it stands initializes only the first element of each array.
--jg
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
