DSXchange

I've added the missing Perform statement into the code.

I used @USERNO in case more than one user runs the code at the same time. This can be any system-wide-unique identifier.

This is a really strange error. When connected (to AIX) via telnet, I have seen this message using the du . command. # Let's start somewhere $ cd /home/dsadm/projects/eswm/dev/data/reject $ du . du: can't find current directory $ du /home/dsadm/projects/eswm/dev/data/reject du: can't find current di...

Do you have SELECT privilege to the pertinent system tables in which the table and column metadata are stored?

Even an "all T" word investigation might be enough for this particular requirement.

Unfortunately I have no TX skills so can't advise how to contruct the map to manage the conversions.

Provided you have been paying the annual maintenance charge on your 7.5.2 licence, there is no charge for the licence upgrade to 8.1.

(You will, however, probably incur costs related to heavier-duty hardware.)

It happens automatically as your projects are upgraded or, if you prefer export/clean install/import, as your components are being imported.

ProjectJobNames = "" Ans = @NULL * Open VOC file - error handling omitted for clarity Open "VOC" To fVOC Else GoTo ErrorExit TempVOCName = "JOBS_" : @USERNO * Get list of project names Query = "SELECT SCHEMA_NAME TO SLIST 9 FROM UV_SCHEMA WHERE SCHEMA_NAME <> 'CAT...

From where I sit, the answer is "almost certainly not" unless you can track down someone who has already built one. If IBM had one they probably would have shipped it.

During real time you pass back the standardized result, "for better or worse".

Operator role can not start most jobs. Operator role can only start "released" jobs, which almost nobody uses any more.

Who is "guyz"?

Unfortunately the original requirement was to get it working in a server job.

Your routine could create a temporary VOC entry that points to DS_JOBS in each other project in turn.

I don't have that information readily to hand, and it's not published. In DS_JOBOBJECTS you need to look at those objects whose OLETYPE is like 'C%Input'. I have no idea where in the record the partitioning information is actually located. And it may well be enumerated.