RE: Common Display File (Header + File-level Keywords) -- MIDRANGE-L

Yes I have seen it, and you aren't kidding about it taking a while - that document is almost 800 pages of I-don't-know-what-I'm-looking-for! The screen I am attempting to re-create is not a complicated one (no windows or tabs or dropdowns) - I am just trying to establish a maintainable format. I have seen only two mentions of trying to create a setup like this and I think they both came from web developers trying to work with green screens (and of course the results were not posted). IBM documentation has not been helpful to me, unfortunately, because anything written with modern application design in mind does not use DDS for the UI.

I can get two screens to display at once with the information available, but I cannot determine how to have a set of default file-level keywords and available function keys that I could add to every screen I make (without copy-paste). I think this would require having both the base screen (with the defaults set) and the main screen "active" at the same time, but it seems it is only possible to have a single screen active at a time (is this what you mean when you mention using windows? Do they allow the function keys from the screen below to remain active?). Either that, or there is maybe some way to set these parameters in the RPG before the EXFMT? Otherwise, I believe my only option is a precompiler.

Thanks,
Sarah

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Vernon Hamberg
Sent: Wednesday, January 29, 2014 3:28 PM
To: Midrange Systems Technical Discussion
Subject: Re: Common Display File (Header + File-level Keywords)

Sarah - have you seen the "Application Display Programming" manual from IBM? It would answer most of what you are asking, although it might take you a while to get to each area.

But there are examples there of doing various things that might help you.

You are going from web to 5250 - the usual thing today is from 5250 to web, and often parts of the 5250 screen are parceled out to index tabs, say, to give better landscape.

Now it is possible to have windows overlay a screen, and those windows can have the smaller bits or the things you would have had in tabs - maybe that's a way to go - take your tabs and make DSPF windows of those, then assign F-keys to make them be displayed over the main screen.

HTH
Vern

On 1/29/2014 5:05 PM, Sarah Kemp wrote:

Thanks for the explanation. In this scenario, is there a way to set the file-level keywords and available function keys in one file and use them across the whole application, or do their definitions need to be present in each display file? Is there some way to set these with RPG or do they have to be compiled in with the DDS?

Thanks,
Sarah

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Dan Kimmel
Sent: Wednesday, January 29, 2014 2:52 PM
To: Midrange Systems Technical Discussion
Subject: RE: Common Display File (Header + File-level Keywords)

The best I've ever been able to do to accomplish what you're trying to do, is to divide each "working section" of the screen into a separate display file with its own program and overlay the screens. So I have Program A that calls program B to clear the screen and display header and footer sections and then calls one of several programs in some order that overlay the middle section with perhaps a subfile or other entry form. Those programs restore the screen and return information to Program A. Program A records the information and determines which program to call for the next "subscreen". Also use "popup" screens for choosing one of many values, for instance; one can reuse the same program and display file for many kinds of lists.

You can also accomplish the same thing with many "records" in a display file managed by a single program.

The old rule was one display file per program, but newer versions of RPG allow a display file per sub-procedure.

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-
bounces@xxxxxxxxxxxx] On Behalf Of Sarah Kemp
Sent: Wednesday, January 29, 2014 10:06 AM
To: Midrange Systems Technical Discussion
Subject: RE: Common Display File (Header + File-level Keywords)

It's true I'm coming from a web background. I can't remember the last
time I made a page that was actually all located in one file so I am
trying to get these green screens working with the same flexibility.
I'm looking for a combination of CSS and a PHP (or ASP) 'include',
which just grabs the header file (which could have standard config,
output, and style information) and adds it to the page. I am ok with
this 'grab' being at compile time rather than runtime, but I really
don't like the idea of just having a template that I copy and paste into each new screen... what if something changes?

I'm really struggling with the limitations of DDS. I did see this preprocessor:
http://rpglanguage.biz/copybook.html. Not being very familiar with
iSeries terminology, it sounds like it might be capable of allowing a /COPY in my DDS.
Has anyone had any experience with something like this?

Thanks,
Sarah

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-
bounces@xxxxxxxxxxxx] On Behalf Of rob@xxxxxxxxx
Sent: Wednesday, January 29, 2014 6:13 AM
To: Midrange Systems Technical Discussion
Subject: RE: Common Display File (Header + File-level Keywords)

Sounds like she's trying to do a DDS version of Cascading Style Sheets (CSS).

Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600
Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com

From: Alan Cassidy <ACassidy@xxxxxxxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Date: 01/29/2014 08:58 AM
Subject: RE: Common Display File (Header + File-level Keywords)
Sent by: midrange-l-bounces@xxxxxxxxxxxx

....If I use a WRITE header followed by an EXFMT main screen, only
the

main screen is displayed and none of the file-level keywords from the
header are active.

Use the OVERLAY keyword on the EXFMT screen, and watch your header
record
remain:
http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/index.jsp?topic=%2Fr
zak
c%2Frzakcmstoverla.htm

I have also seen advice to designate a header field in your display
file

and customize it in your program in order to allow a more
standardized header, but I don't know how (or if) it can be used with
file-level keywords and allowed function keys?

Probably header fields (plural). Most of mine show a file/screen name
upper left, application name in the middle, date and time upper
right, a subtitle on the 2nd line centered. Go by shop standards,
and/or clone somebody's DDS code and customize to your specifications.

If this is not possible, how is screen standardization usually handled?

Shops vary on this one, but almost all of them are pretty definite
about that. If they don't seem to, or it's a tiny shop, they might
not, in which case I have usually simply tried to find what most of
the screens already look like to the users and take it from there.

(Would that more shops were pushing for Web interfaces)..

Alan Cassidy

At Caledonia Financial Services
acassidy@xxxxxxxxxxxxxx
954-693-0000 ext. 3433 - Direct phone
786-380-9236 - Mobile phone

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [
mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Sarah Kemp
Sent: Tuesday, January 28, 2014 5:38 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Common Display File (Header + File-level Keywords)

I learning about RPG and DDS for screens and I am trying to determine
if there is some method of including or referencing one DDS screen
inside of another. What I want to be able to do is create a "common"
display file that has, for instance, the company name and the date,
and includes some file-level keywords and allowed function keys
(INDARA, CA03, etc.). Then, ideally, I would be able to create
program-specific screen content in a separate file without having to
redefine the common function keys, header information, and file-level keywords.

Is there a method of including DDS source with something like a
/copy? Or can I use two display files in one RPG program and have
their allowed keys and keywords both active at the same time? I have
tried using two in one program, but I can only get them both to
display by using EXFMT rather than WRITE for the header file, which
means control needs to be returned before the main screen is written.
If I use a WRITE header followed by an EXFMT main screen, only the
main screen is displayed and none of the file-level keywords from the header are active.

I have also seen advice to designate a header field in your display
file and customize it in your program in order to allow a more
standardized header, but I don't know how (or if) it can be used with
file-level keywords and allowed function keys?

If this is not possible, how is screen standardization usually handled?

Thank you,
Sarah
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L)
mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To
subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take
a moment to review the archives at
http://archive.midrange.com/midrange-l.

---------------------------------------------------------------------
----------- Confidentiality Notice: This email may contain
confidential information or information covered under the Privacy
Act, 5 USC 552(a), and/or the Health Insurance Portability and
Accountability Act (PL 104-191) and its various implementing
regulations and must be protected in accordance with those
provisions. It contains information that is legally privileged,
confidential or otherwise protected from use or disclosure. This
e-mail message, including any attachments, is for the sole use of the
intended recipient(s). Any unauthorized review, use, disclosure or
distribution is prohibited. You, the recipient, are obligated to
maintain it in a safe, secure and confidential manner. If you are not
the intended recipient, please contact the sender by reply e-mail and
destroy all copies of the original message. Thank you.
---------------------------------------------------------------------
-----------

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L)
mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To
subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take
a moment to review the archives at
http://archive.midrange.com/midrange-l.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L)
mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To
subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take
a moment to review the archives at
http://archive.midrange.com/midrange-l.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L)
mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To
subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take
a moment to review the archives at
http://archive.midrange.com/midrange-l.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.