Runprint from the command line in SP23/SP24...

[swhitmire]

We've run into a problem in our testing of SP24.0.2. We have a script that calls runprint directly from the command line to create a sort of selective print immediate functionality. When we upgraded from SP23_K1 to SP23_R1 some time ago, we discovered that Oracle has apparently changed the parameters for runprint, as it doesn't work the way we're calling it any more. We got around that by just saving an old copy of the runprint executable and calling it from our script, but now that doesn't work either -- the old runprint gives an error when run on the machine where we've installed SP24. Running strings on the executable shows the same "RUNPRINT:user:%s: Env:%s: Job:%s: cPrint :%c: szPrinter :%s" found in the old one, but calling it like "runprint JDE file_with_password PD7333 12345 Y" no longer works. (I'm going to ask Oracle, but they're probably going to say what they always have, which is that you can use it only if you can figure out for yourself how to make it work. I'd search on Metalink3 to be sure, but the search seems to be broken at the moment.)

So, has anyone managed to figure out the right syntax for calling runprint directly in recent service packs? If we don't get it figured out we're going to have to put off our plans to move to SP24 week after next, so any help is appreciated!

 

[swhitmire]

Got a reply from Oracle... said just what I expected, that the parameters are a secret, and we have to guess them for ourselves if we want to use them. I understand that they don't want to support using it this way, but it's really frustrating that they won't even tell me what they changed.

The document where they explain this (644362.1, which I had looked at before but was hoping they'd forgotten they wrote

) suggests looking at the debug log for a UBE to figure it out, but it doesn't seem to show the parameters. Sigh.

 

[swhitmire]

Well, I figured out where it gets logged -- it's in the debug log for the actual runprint process that gets spawned. (I think that may be how we figured it out in the first place, actually, but it's been so long I've forgotten.) Unfortunately, the line that shows up when I run one by checking the Print Immediate box in JDE and the line that shows up when I run one by hand look just the same, even though one way actually prints and one doesn't:

Aug 26 13:59:36 ** 2121860 RUNPRINT:user:JDE: EnvV7333: Job:63127: cPrint :Y:

Aug 26 14:24:51 ** 1716376 RUNPRINT:user:JDE: EnvV7333: Job:63127: cPrint :Y:

It doesn't show the password (or the name of the file the password is in) so maybe it has something to do with that.

 

[swhitmire]

I still haven't found how to make it work... the Oracle support guy has sent the question on to the developers, so maybe they'll take pity on me and share the secret.

I'm wondering, though, if the thing actually works at all any more... I don't think when you run a UBE the regular way it's actually calling the standalone runprint executable -- I replaced it with a script that just echoed its own parameters to a file and then ran a UBE with Print Immediate, and the output file never got created (even though the PDF did print). So I'm thinking the runprint functionality is also in the runbatch executable or something, and maybe the reason I can't get it to work is that it just doesn't work. Any insight into any of this is, as always, greatly appreciated.

 

[Segfault]

Have you set
[DEBUG]
Output=FILE

just before running runprint, and gotten the jdedebug log from the process id? (You can set it back to =NONE as soon as it runs, that will turn it on just for the new e1 procs that start during that short window)

Might be a clue in there...

 

[swhitmire]

Yeah, that's where I got these lines in my earlier post:

Aug 26 13:59:36 ** 2121860 RUNPRINT:user:JDE: EnvV7333: Job:63127: cPrint :Y:

Aug 26 14:24:51 ** 1716376 RUNPRINT:user:JDE: EnvV7333: Job:63127: cPrint :Y:

One's from doing it by hand and one from just running the UBE with Print Immediate checked. They look just the same, as if runprint is correctly matching up the command-line arguments with its expected parameters, but one works and the other doesn't.

 

[Segfault]

What else was in the jdedebug.log (not the jde.log)?

Could it be you are using the same password file, but in the sp24 release, the user id running services doesn't have read permission on the password file?

 

[swhitmire]

Nothing else exciting in the debug log (I don't have the ones I made a couple of days ago anymore... I'll make another set and check again later.) The password file actually gets re-created every time by the script because runprint removes it when it finishes, so the same user creates the file and executes runprint.

 

[Segfault]

ok, I'd get the script out of the picture. Manufacture the the password file, and run runprint by hand, and do it as the same user id that is running the services.