|
James, In a message dated 98-07-22 22:32:13 EDT, you write: <<snip>> > Unfortunately, it's the differences that must be pointed out to prevent " business > as usual" solutions. Amen to _THAT_! > One small example: On the AS/400 I can not change a display file while it is in > use, but I can change a program although any active users continue to use the > older copy. I'm sure there are a myriad of reasons for this situation, but with > a "broadened" solutions viewpoint a web page can be changed while it is use and > the user automatically receives the new page upon next display. As long as that "older copy" isn't an in-house API that performs a RETRN rather than setting on *INLR ;-)! <<snip>> > The point to ponder would be how much logistical resources are consumed in > timing the implementation of a modification? Between shifts? If your shop is 24/7 > it would mean worker down time. I don't know about the rest of you, but I've been > told by my clients that amounts to about $10k/hr. to have idle staff. As Rob > pointed out, a real-time enabled environment would make a big difference on > the ability to "deliver" solutions. _EXCELLENT_ point! Our only down time is an eight hour window on Sunday. Even with a CMS installed, the calibre of people running forms on Sunday is suspect at best. When a problem comes up (say, someone came in and was using the program in Production when they shouldn't have been, thus having the display file locked) the weekend folks (when they call at all) usually don't call until it's going to be another week before the form can be promoted. Taking our plant off-line for mission-critical applications is _CONSIDERABLY MORE_ than $10K per hour -- most shop floor reporting happens through over 100 terminals and touch screens via a mere _TWO_ programs. Change either of the latter, and you've got a mess on your hands (especially if the change ends up needing to be backed out). We've tried for as long as _FOUR WEEKS_ to get a change into Production on our shop floor transaction processing programs -- meanwhile paying someone _big_ bucks and taking _big_ chances with data damage to manually fix the problems caused by the malfunctioning program... > Who knows, maybe V5 of OS/400 will not treat display files like physical files > and permit a shift to QRPLOBJ, like programs do, while it's still on a user > screen and upon next display/call the OS will check date/time and bring in the > newer copy automatically. Yeah, they've _HAD_ this with menus since at least V2R3, except that it doesn't go far enough. I usually get elected to change the menu that we all sign on to because I nearly always work late. Once everyone else is signed off, I hit the F-Key to go to the AS/400 main menu and can compile the initial menu with impunity -- even though a simple <F12> will send me back to the newly-modified menu. Why can't this work with _ALL_ display files, without having to go somewhere else? > Now we've all been there, we need a new variable on a screen, x gazillion people > are logged onto the program that uses that screen, they're on the phone to > customers, paying customers, and the big guy does not want disruption of > business but he realllly wants the new variable. What are you going to do? > Hang your head or stand proud and declare "Can do!"? Today, hang your head... > OK, I didn't intend to get into it this deep, but...... > > DDS is a buffer to variable mapping facility. Your program receives input from a > WORKSTN file which does buffer to variable parsing to your program. As long as > you do not change the buffer position of a variable (or length which bumps all > others) you do not have a level check and all is good. But DDS is compiled and > fixed at a point in time. Now let's say that, from a design viewpoint, you > declared ALL variables as variable length. If, and it's a big IF, what if DDS > could do variable length input like a <FORM> type text HTML page could do? > How long is the customer name? Who cares! Errrrrrr! I'd declare SOAPBOX MODE(*ON) here, but I've already been there! DDS for DSPF's remains what it was back when IBM machines first got two-digit system designations -- a "graphical" (HA!) representation of punched cards. Much like the 5250 data stream, DSPF structure should have been re-written for the /400 -- I've never seen either an MFCU _OR_ a 5250 actually _SOLD_ with a new AS/400. The only buffers I want are "BUFFERINs" when I start thinking about why this ancient DDS technology was grafted into an otherwise forward- thinking system. > Now the purpose of fixed length variables and fixed length records has > (historically) been speed. That song sold then but hey!, drives are faster now. > Not only that, they're cheaper too! Amen, again! Dean Asmussen Enterprise Systems Consulting, Inc. Fuquay-Varina, NC USA E-Mail: DAsmussen@aol.com "A lot is two words. ALOT is _NOT_ a word at all." -- My 10th Grade English Teacher +--- | This is the Midrange System Mailing List! | To submit a new message, send your mail to MIDRANGE-L@midrange.com. | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com. | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.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 on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.