DSXchange

They are all of the specifically named kernel parameters for your O/S that are listed in the Installation Guide.

So... you think you are having 'issues' getting help? :? You've got quite a large, active volunteer user community here perfectly willing to help, perhaps even willing to supply 'hundreds' of jobs. As noted, I for one cannot - it comes from being a consultant for a client in the health care industry...

And note they are typically mentioned twice in the file.

Select each one and then examine the generated sql, the difference should be easy to spot. And 'clear' here means a 'transactional delete' of all rows in the table, as opposed to a truncate which is not transactional.

Array size really doesn't have anything to do with it. Transaction Size = number of rows to commit at a time in the database.

99.99% of the time you should just stick with the default 'Type30' Dynamic hashed file via the stage and you'll be fine. Otherwise, you're off into the Static hashed file realm along with the requirements they bring to really be effective / useful.

Welcome aboard. :D Sorry but that's not really how it works. For me, any jobs I have are property of my client and contain information private to their business, so they're not about to be sent out to anyone. Now, that doesn't mean someone couldn't build generic example jobs and send them out, but I...

No, all you need to do is make sure your script exits with a non-zero status if your load has a problem, the job will notice and abort automatically.

Would you mind sharing why you think you need to be compiling things from the command line? Overly curious minds want to know...

In other words, there is no error. Your processes no longer exist, which is why Cleanup Resources says what it does, but the internal locks associated with them still are there, hence the list.readu output.

Do a search for "OpenFileMapping" and see if any of the other 18 posts have a resolution for you.

Well... bare bones you pass the job parameter as an argument to the script and then reference it as $1 when you make the "osql" call, assuming it is the only (or first) thing passed.

Give it a try and see. If it does not resolve the job parameter, you'll need to write a wrapper script that does the actual "osql" call and pass the parameter to it. That's generally a better solution anyway, it's more robust and you have more control that way.

No need, "blanks" aka spaces work just fine here and are handled no different than any other character. Like all reference lookups, they just need their values to match on both 'sides' of the key, Char(2) to Char(2). Just to put the last nail in this, I built a simple test job that creates...

As noted, I wouldn't even consider touching those values except under the direct counsel and guidance of support. Seriously.