Sending a Command 7 from OCL

[Guest.Visitor]

I'm modifying a procedure for the S/36 which requires the operator to perform several <7>s -- I want to make this an unattended procedure but have been unable to find any information on how to send the <7> via the OCL. I'm Sure it can be done, but I've ran out of ideas. Thanks in advance.

[D.Handy]

Sending a Command 7 from OCL

MJ, I'm modifying a procedure for the S/36 which requires the operator to perform several <7>s -- I want to make this an unattended procedure but have been unable to find any information on how to send the <7> via the OCL. You can't send keystrokes from OCL (to my knowledge). What exactly are you trying to accomplish? On the S/36, Cmd7 was typically used to exit a program, or cancel a prompt in OCL. Is the operator using a series of Cmd7's to exit/cancel a function, or as part of responding to initiating a function which continues? Are you dealing with // PROMPT screens from the OCL, or RPG Workstn programs (or COBOL, etc)? Are you trying to avoid having the screen displayed in the first place, or once Cmd7 is done on one screen are you trying to suppress the display of more prompts and return back to the menu? If the latter and the screen is displayed via // PROMPT, then add something like this to the OCL:

 // PROMPT MEMBER-... // IF ?CD?=2007 RETURN 

Which will end the current procedure when Cmd7 is pressed. If the procedure was nested, the previous procedure will regain control. To avoid that, specify CANCEL instead of RETURN. Then all nested levels will be canceled and you will return to the menu. If this doesn't answer the question, give us more specifics on what you are trying to accomplish. Doug

[D.Handy]

Sending a Command 7 from OCL

MJ, I'm modifying a procedure for the S/36 which requires the operator to perform several <7>s -- I want to make this an unattended procedure but have been unable to find any information on how to send the <7> via the OCL. You can't send keystrokes from OCL (to my knowledge). What exactly are you trying to accomplish? On the S/36, Cmd7 was typically used to exit a program, or cancel a prompt in OCL. Is the operator using a series of Cmd7's to exit/cancel a function, or as part of responding to initiating a function which continues? Are you dealing with // PROMPT screens from the OCL, or RPG Workstn programs (or COBOL, etc)? Are you trying to avoid having the screen displayed in the first place, or once Cmd7 is done on one screen are you trying to suppress the display of more prompts and return back to the menu? If the latter and the screen is displayed via // PROMPT, then add something like this to the OCL:

 // PROMPT MEMBER-... // IF ?CD?=2007 RETURN 

Which will end the current procedure when Cmd7 is pressed. If the procedure was nested, the previous procedure will regain control. To avoid that, specify CANCEL instead of RETURN. Then all nested levels will be canceled and you will return to the menu. If this doesn't answer the question, give us more specifics on what you are trying to accomplish. Doug

[Guest.Visitor]

Sending a Command 7 from OCL

Thanks for the quick reply! The situation we are dealing with is rather complicated, and I have a feeling it may be one of those "you can't get there from here" sort of things. We are receiving files from an RS/6000 via a Windows NT system that is creating a virtual folder on the S/36. We are then translating the files from ASCII to EBCDIC to allow us to use the files on the S/36. This whole process is performed with a great deal of operator intervention, due in large part to the fact that we have found no way to automate some of the processes. (Apparently Display Write controls the Folder and Document functions, and it doesn't support the use of LDA and OCL, or at least we haven't found a way to do so thus far.) I realize this sounds confusing, but I think the Main stumbling block is the fact there is no "send key" function on the S/36. Thanks again for your earlier reply.

[D.Handy]

Sending a Command 7 from OCL

MJ, This whole process is performed with a great deal of operator intervention, due in large part to the fact that we have found no way to automate some of the processes. (Apparently Display Write controls the Folder and Document functions, and it doesn't support the use of LDA and OCL, or at least we haven't found a way to do so thus far.) I'm still not clear what you are trying to accomplish, so I can't give specific suggestions. Are you trying to create documents for use with DW/36? You may want to look at all the variants of the PCU procedure. Given the right parameters named on the procedure call, you can perform all kinds of functions and conversions in an automated batch environment including exchanging data between a data file and virtual disk file, between a virtual disk file and DW/36 document, etc. And you can modify the EBDCDIC to ASCII conversion tables it uses if you need to. I once had to setup an automated method of creating DW/36 documents including features not supported by PCU functions. It was part of an application program generator I wrote back in '87, which generated the RPG, $SFGR, and OCL for interactive programs and automatically compiled them. I then wanted to add document style help text with field-level "help tag labels" for cursor sensitive help text. Since they were a somewhat non-standard part of the Revisable Format Text Document Content Architecture, I had to devise a way to generate a RFT-DCA document under program control and make DW/36 think it was a regular document. To do this, I used the ARCHIVE procedure to dump some documents to a disk file to study the file layout. Then I wrote my programs to generate stuff in an equivalent format, which included all kinds of bit dwidling to get the binary offsets correct for various RFT-DCA text instructions. My program would generate and "write" the document into a disk file, then use the RETRIEVE procedure to "restore" the document from the disk file into a folder. It was a fun project, and saved countless hours of time. But the concept of using ARCHIVE/RETRIEVE in this manner is not supported by IBM -- they were designed as a method of putting documents to/from a file for transfer via comm links since you couldn't transfer folders directly except via diskette or tape. Depending on what you are trying to do, another alternative may be to use a PC running emulation. Then write a PC program which uses APIs to send keystrokes to a session. You can get real sophisticated with some of this stuff by examining and modifying the 5250 buffer instead of just being a simple macro-style playback of keys. I think the last time I did one of those was 9 or 10 years ago... It's probably not a matter of "you can't get there from here", but sometimes it does get a little more complicated than it seems like it should. Doug

[Guest.Visitor]

Sending a Command 7 from OCL

Re: >>>I'm still not clear what you are trying to accomplish, so I can't give >>>specific suggestions. Are you trying to create documents for use with DW/36? Up until recently we have had a procedure in place which multiple remote locations called into a PC and uploaded transaction files to that PC. Then, in turn, we used PCTRAN to upload these files to the S/36. It was decided that this procedure would be replaced by having the PCs call in to an RS/6000 -- this created a need to find a way to upload these files to the S/36 (with no additional expense) As a result of this change in situation, the MIS director of the company decided to use the network to transfer the files to a Windows NT system, which has a virtual folder set up on the S/36. In order to be able to process these files on the S/36 it was decided to use the Folder functions to accomplish the transfer. As it was explained to me, it, the process required the use of some Display Write functions -- none of which supported OCL or LDA. You have to forgive me if I should a little hazy on this, I've "inherited" this process after it was set up, and I'm trying to figure out a way to avoid having an operator go through a 6 page set of instructions every time we want to upload a file. After reading your last reply I checked the procedure the MIS director set up and it does use a series of PCU commands to create a Virtual folder and translate the files in question. One thing that may be complicating this issue is the fact we do not know ahead of time what the file names for upload will be, or how many of them there are. Thanks for your help and patience in this matter -- this sort of processing is a bit outside my area of expertise. (I'm a mixture of old school 34/36 and PC/NT)

[D.Handy]

Sending a Command 7 from OCL

MJ, After reading your last reply I checked the procedure the MIS director set up and it does use a series of PCU commands to create a Virtual folder and translate the files in question. Is this what was used with the former PC dial-up configuration, or what is being used now with the RS/6000 to NT to S/36 shared folder configuration? Are you getting the files into the shared folder correctly? Is this automatic when a file is received on the RS/6000? Do you process a file as soon as it hits the RS/6000, or is it a batch process run periodically? One thing that may be complicating this issue is the fact we do not know ahead of time what the file names for upload will be, or how many of them there are.} So these are really data files, not documents, and you are trying to get them from the folder members into data files you can process, right? Does the operator take one folder member at a time, transfer it into a specific data file, process it, then repeat for each other member? Does the data file name vary with the folder member's name? Doug