Re: A Query question.

geir.kildal wrote:

Yes - this may not belong here - but I'm only onto this list for the
time beeing.

Geir:

The idea of it 'belonging' here is to help you first. Should you expect COBOL experts to have any good suggestions about your question? If you want a good answer, you should ask where experts can see the question.

But second, the idea is to help others who come later. Why would anyone search the COBOL archives to find details about query products?

But if you don't need good answers, then the COBOL list is as good as any, I suppose.

That's not a serious complaint; merely my way of thinking about these forums.

I' just changed a couple of central files in my COBOL-system and
recompiled - all well, but I also have a huge number of querys which are
using the same files. I have to open and close them to make them pick
up the new file definitions.

My question is: Do I have to do this manually one query by one - or is
there a cunning method of some kind that will do this for me?

It depends on what kind of "query" these are.

Are they Query/400 *QRYDFN objects? Then, yes, they'll need be opened individually, and probably manually.

Are they Query Manager *QMQRY objects? Then, as already noted, you probably don't need to do anything to them; although, each one should be tested in case there is a specific dependency on something you changed. Personally, I haven't really used Query/400 queries since shortly after QM queries and forms became generally available, maybe 15 or more years ago.

Are these queries bound into programs? Something else?

Anyway, for *QRYDFN objects, you might investigate the creation of PC5250 macros to help automate the process. Maybe you can get a large majority handled simply by automating the key-stroke sequences. Once most are handled, smaller solutions might be useful for the rest.

Also, consider Albert York's TNAPI - a Telnet API. One download site:

http://think400.dk/downloads.htm

If 5250 macros are infeasible, then some TNAPI programming might still be possible.

Tom Liotta