Advice needed on ISPF/REXX problem with DB2 upgrade

ozburt · New User Joined: 05 Nov 2009 Posts: 5 Location: UK

Since migrating from DB2 Version 7 to Version 8 we have had issues with
generating IBM Utility JCL, which is done by performing SQL queries on the DB2 Catalog tables. We believe that the problem lies within the TSO/ISPF Call Attachment Facility (CAF) which is accessed via a REXX assembler macro, DB2ISPF2, but have been unable to identify the cause.

We have updated all the various libraries so that they are V8 compliant and this is reflected in the assembler macro.

The generation of IBM Utility JCL worked in V7 but not in V8.

At first we thought it was due to the increased length of columns in the
DB2 Catalog tables but this was ruled out.

However, further investigation revealed the following errors:

Variable 'NUM_DEP_' is syntactically incorrect

Variable 'SPLIT_RO' is syntactically incorrect

These columns are derived from SYSIBM.SYSTABLES - NUM_DEP_MQTS
and SPLIT_ROWS, both of which are new columns in V8.

In the ISPF manuals it states:

ISPF variable names are 8 characters or less, and consist of alphanumeric characters only. The name must start with an alphabetic character. Rexx stem variables are not supported.

Prior to V8 all columns within the SYSIBM.SYSTABLES are alphanumeric for the first 8 characters with any special characters such as underscore coming after the 8th character.

So it appears that with the introduction of new columns in DB2 Catalog tables in V8 that contain an underscore within the first 8 characters of the column name has an adverse impact on our REXX/ISPF/DB2 routines.

Does anyone know how to get round this problem or has a piece of REXX
code to circumvent this?

enrico-sorichetti · Posted: Fri Nov 06, 2009 5:46 pm

ozburt · New User Joined: 05 Nov 2009 Posts: 5 Location: UK

Enrico

Sorry if you took offence and great exception at what was my first posting to the forum. I thought the whole purpose of forums of this ilk was to provide advice and get ideas from others on possible solutions or to be guided in the right direction.

It was just a simple request for suggestions/advice on what to do with regard to the REXX code when interfacing with ISPF for variables when it comes across an underscore within the first 8 characters which is rejected by ISPF.

You have recognised that it is not a DB2 issue so that is why it was posted in this forum.

The rexx code was attached as a reference aid (used from DB2 Update journal) but if it meets with your disapproval then by all means remove it.

Hopefully I will get some pointers as I will admit that I am no rexx expert rather than to be made unwelcome.

Regards

Ozburt

wanderer · Posted: Tue Nov 10, 2009 5:46 am

Hello,

This looks like an inhouse developed tool. After V8 we also had several problems with REXX and some panels. But nothing of the type as yours. But then it all depends on what catalog tables you are using what you are doing with them, processing using ISPF etc.

I think you are the best person to fix this. It will be easier if you could provide specific details about error and exactly the place in code where it happens. If you can hide your application details and ask specific technical question, you would have a better chance of getting an answer.

My 2 cents.

enrico-sorichetti · Posted: Tue Nov 10, 2009 6:21 am

I did not take any offence nor exception...

You did not ask about any advice,
You were complaining about the odd behavior of an in house developed tool
when migrating to a new version of db2 and asking for help in debugging Your tool...

I downloaded the tool source, read it ( or rather read the usage instructions ) ,and posted my findings

... not a db2 issue nor a REXX issue either,
I am going to repeat it ...
a poor understanding of the internals of Your tool
or a poor way of implementing it ( somebody did not read the documentation )
which had as a consequence not using properly the facilities provided by the tool itself.

what was attached was an assembler code which issues a dynamically built
select and with the results of the select fills an ispf table

to fix the error reported there is no need to be a REXX expert because
nowhere in the starting post of this topic there was mention of rexx

You took exception on my comment with the evil emoticon
apart the emoticon what is that You disagree with in my comments ?

I just did what somebody in Your organization should have done in advance ...
reading and understanding how to invoke the tool when the DB2 column names
do not respect the ISPF naming constraints

the fix for the issue looks very clear to me ...
when selecting columns with names that do not follow the ispf rules use the provided alias facility
as explained in the documentation inside the assembler program

that' all ...