Yes - it is possible to do this. Add extra fields to the display file after the last IBM-provided field UBUFFER. Use DDS keyword MSGID( ) where = name of the message file you want to use and = the message ID containing the text you want to display.

You can use as many message-derived fields as will fit on the screen. Each message field size can be anything from 1 to 132 bytes (I think that's the maximum length of 1st-level message text - someone will correct me if not).

I'm sure you know this already - but since I've been a victim in the past - ensure that you don't resequence your DDS fields in SDA and that you add all extra fields to the end of the DDS source. Also, you need to compile QDSIGNON as LVLCHK(*NO).

---

There are products (check ProSign/400, AS/SURE) that will allow you to change your signon screen. They might help you do what you need to do.

Now, a bit of a change in subject - both these products allow you to make changes while the subsystems are up, without recompiling the screen, bringing down the subsystem, etc. Just curious here, how do they do that?

---

If you use message fields (see my earlier reply) then the contents of the sign-on screen change every time the underlying message text changes. I use this to show a real-time display of date & time + % disk used by updating the sign-on screen messages every minute from a background server job. Every time I press Enter on the signon screen without actually logging on (e.g. by leaving user-ID blank), I get the current time etc. refreshed on the sign-on screen.

---

In addition to the other comments, here is an observation on the subject. If most of your users are connecting via Client Access they will not see the Sign On screen and therefore will not see your message. I had once changed the Sign On screen and put a daily message on it, but as we migrated to PCs it became a wasted effort so we stopped it.

---

We have the following on our signon screen:

A            MSG001        60A  O 19 11MSGID(ON001 DPLIBR/ONMSGF)
A            MSG002        60A  O 20 11MSGID(ON002 DPLIBR/ONMSGF)
A            MSG003        60A  O 21 11MSGID(ON003 DPLIBR/ONMSGF)

To change the message text on the signon screen, we just CHGMSGD for the line we want changed. This does not change the menu interactively - if a workstation is already dislplaying the signon screen, it does not change. The change will only show up on the next initial display of the signon screen - like when the terminal is powered on, the PC starts emulation, or the user signs on then back off.

---

A message field is the best way to do this for QDSIGNON (or your own signon display file). A routing program that pops up an info window before TFRCTL QCMD might be better, to catch those who bypass signon.

For a message field, I currently use:

     A            MSGLINE      640A   O 13  1

with keyword MSGID(SYU 0001 SYUSRSYS/SYUSRMSG)

The length of 640 gives me eight full lines I can fill. In order to actually get that much into the message, you must use second-level text rather than first-level text. In order to make second-level text available, all you need to do is specify nothing but the message ID in the first-level text. So, in the case of my example, first-level text for message ID SYU0001 is simply... 'SYU0001'. Be prepared to look long and hard for the documentation on this though. But it is more or less documented and it's a base part of the S/36 support, so IBM assures me it will continue to work.

And if all you are doing is adding message fields, you shouldn't need LVLCHK(*NO). At least, I don't use it and my format level identifiers don't change. If you add an actual input or output field, however, this will no longer be true.

---