MIDRANGE dot COM Mailing List Archive



Home » MIDRANGE-L » August 2014

Re: Prompting WRKOBJ command shows Major Command Groups menu



fixed

Yes, XXX F4 fails with

Message ID . . . . . . : CPD0030 Severity . . . . . . . : 30
Message type . . . . . : Diagnostic
Date sent . . . . . . : 08/28/14 Time sent . . . . . . : 16:56:07

Message . . . . : Command XXX in library *LIBL not found.

I'll work on the trace job tomorrow.


Here's a new wrinkle. I signed on as the test user, and entered WRKOBJ f4, which failed.

Then I entered WRKOBJ with no parameters, and it prompted.

And the wrinkle is, I then did WRKOBJ F4 and it prompted.

And the command I was developing (HS0340) also worked. Without having to do HS0340 ENTER first.





On 8/28/2014 12:43 PM, CRPence wrote:
On 28-Aug-2014 10:42 -0500, Peter Dow wrote:
When I enter WRKOBJ at a command line and press F4, I'm shown the
Major Command Groups menu, as if it did not see the WRKOBJ I entered.

And the effect from typing a non-existence command name followed by F4=Prompt? The expected CPF0001 preceded by a diagnostic CPD0030 "Command &2 in library &3 not found."; similar variations of a test of the F4 effect for a command string that should knowingly effect CPF0001 arising from any of the various other CPD003# message conditions [or similar] might reveal something not conspicuous when using a command that knowingly should prompt without errors.

Of course, a circumvention is to precede the command-string with a question mark (?) character and press Enter instead; to effect what the F4=Prompt should have done. For example: ?WRKOBJ

However, if I enter WRKOBJ X, it tells me it cannot find X.

Conspicuous in the difference between that and the failing F4, pressing Enter does not invoke the Command Prompter (PT) feature.

I'm using TN5250J version 0.7.3 (my prime suspect) to connect to an
IBM i with OS 7.1, PTF group SF99710 level 13037 (low on my list of
suspects).

I've tried it with two different profiles, and it really seems hit
or miss. Sometimes it works, but mostly it doesn't. Prior to today,
it has worked flawlessly.

If the problem consistently stops occurring [or consistently occurs] when debug is active in the job, then the issue might arise from an issue with uninitialized storage in a system program.

Anyone seen anything like this?

Never. But I have seen my share of bizarre effects over the years; when I had access to the code long before being publicly released :-)

The spooled output from a Trace Job (TRCJOB) likely should help to identify the origin of the issue. The TRCJOB is replaced with Start Trace Job (STRTRCJOB) as I recall, but TRCJOB should still function fine to produce a spool of the tracing] Apparently the CA04 is properly being sent, else the GO MAJOR would be even less likely than any other effect. Given the PF4 seems to have been processed by the OS, seems somewhat unlikely to be the fault of the emulator; as well, the fact that a cursor positioning issue should have effected CPD6A6D "Additional Message Information".

If traced [I would be willing to review], probably best that the request is started from a separate job after Start Service Job (STRSRVJOB) of the job that will reproduce the issue; a trace of the _exact same action_ for a non-failing scenario would be required for comparison.



---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com






Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2014 by MIDRANGE dot COM and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available here. If you have questions about this, please contact