Ansicht
Dokumentation
00629 - Locking Printers: Mass Processing -Rep ly
PERFORM Short Reference BAL_S_LOG - Application Log: Log header dataThis documentation is copyright by SAP AG.
Locking Printers: Mass Processing -Rep ly
For the good of system, it is better to do this kind of operation in aformal way rather through a back door. CATT script use formal GUI
interactive procedure to do a massive job in batch. Detail information of
CATT can be found in SAP document about CATT. here is our prototype document
for CATT. It might have minor error, but you should be able to work it
through.
<<CATT.doc>>
Regards
Zhihong Zhao
SAP Basis Analyst
DairyFarmers
> -----Original Message-----
> From: Mike Martin, IS, Sousa [SMTP:MMartinZs...]
> Sent: Tuesday, 6 February 2001 8:00
> To: 'JIM DOLL'
> Cc: SAP - AS/400 List (E-mail)
> Subject: RE: RE: RE: Locking Printers: Mass Processing
> -Rep ly
>
> SAPers,
>
> Below is what I discovered in 4.5B:
> TSP03D-PADISABLED - This field is read by SPAD to determine which printers
> are locked, etc. If you select 'Technical Info.'(F1, F9) on the 'Locked'
> field in SPAD, this is the field that the screen uses. This is also the
> field that was used in 3.1H.
>
> TSP03C-PADISABLED - This field is read upon creation of each spool request
> to determine if the pritner is unlocked. When locking a printer in SPAD,
> both tables are updated (see Jim's notes below).
>
> So, after a refresh, I think I will continue with the SQL updates to BOTH
> of these tables to mass-lock/unlock printers.
>
> Thanks to Jim and all others for your help.
>
> Regards,
> Mike D. Martin
> SAP Basis Administrator
> SOLA Optical, USA
> 707-763-9911 x6106
> mmartinZs...
>
>
> -----Original Message-----
> From: JIM DOLL [ <mailto:JDOLLZp...>]
> Sent: Monday, February 05, 2001 10:21 AM
> To: MMartinZs...
> Subject: Re: RE: RE: Locking Printers: Mass Processing
> -Reply
>
>
> I just UNLOCKED a printer, then displayed the journal entries. This is
> what
> I see:
>
> R UB TSP03D R3Q46DATA
> R UP TSP03D R3Q46DATA
> R UB TSP03 R3Q46DATA
> R UP TSP03 R3Q46DATA
> R UB TSP03C R3Q46DATA
> R UP TSP03C R3Q46DATA
> R PX DDLOG R3Q46DATA
> R UB TSP0C R3Q46DATA
> R UP TSP0C R3Q46DATA
> R PX TSP0C R3Q46DATA
>
> Does that help? Can I check 'em out more thoroughly, or are you already
> aware of these?
>
> jdoll
> >>> "Mike Martin, IS, Sousa" <MMartinZs...> 02/05 12:59 PM >>>
> Unfortunately, I have had no time to investigate and I am still unaware of
>
> all the pieces at play here...Any ideas?
>
> Mike D. Martin
> SAP Basis Administrator
> SOLA Optical, USA
> 707-763-9911 x6106
> mmartinZs...
>
>
> -----Original Message-----
> From: JIM DOLL [ <mailto:JDOLLZp...>]
> Sent: Monday, February 05, 2001 9:36 AM
> To: MMartinZs...
> Subject: Re: RE: Locking Printers: Mass Processing -Reply
>
>
> If I recall, the $SYNC didn't do it for our situation--the spool work
> process restart did it. Did you get the pieces parts figured out?
>
> jdoll
>
> >>> "Mike Martin, IS, Sousa" <MMartinZs...> 02/05 12:30 PM >>>
> Thanks for the reply, Jim. SAP was up when I made the change, however, it
>
> was stopped/restarted several times prior to me noticing this strangeness.
>
> I also did a /$sync immediately following the change so that I could
> verify
> via SPAD. I'm almost certain that there are two tables being updated...of
>
> course, I could be wrong.
>
> Thanks,
> Mike D. Martin
> SAP Basis Administrator
> SOLA Optical, USA
> 707-763-9911 x6106
> mmartinZs...
>
>
> -----Original Message-----
> From: JIM DOLL [ <mailto:JDOLLZp...>]
> Sent: Saturday, February 03, 2001 10:07 PM
> To: MMartinZs...
> Subject: Locking Printers: Mass Processing -Reply
>
>
> Mike: Some of those tables are buffered and not refreshed if you work on
> 'em "behind the scenes." Was SAP up or down when you changed the tables?
> I
> remember once where all I had to do was kill the spool work process--once
> it
> restarted, it re-read the tables.
>
> Our PRD and TST systems are on different machines. When I refresh TST,
> the
> spool work process servers aren't valid, and I just leave most of them
> that
> way. I like yours better, cuz they get a message, but mine works!
>
> Longterm (4.6C), we plan to put in duplicate printers, for example, ZBP01
> in
> addition to BP01. Then I can leave the BP01 "broken", but people can
> reroute stuff to ZBP01 if they need too.
>
> We had a FAX go out from our TST system that really confused people until
> we
> figured out that it was not "real."
>
> Jim Doll, Perrigo
>
> >>> "Mike Martin, IS, Sousa" <MMartinZs...> 02/02 7:39 pm >>>
> SAPers,
>
> In 3.1H, I used table TSP03D (field PADISABLED) to massively lock/unlock
> printers in R/3. This is very useful, for example, after refreshing your
> TST
> system and you want to lock all but a couple printers.
>
> Now, we've upgraded to 4.5B. I did a refresh of TST from PRD. I updated
> TSP03D-PADISABLED to lock all printers. I enter SPAD and all printers
> show
> as locked (red). When viewing the detail in SPAD, the flag 'Lock printer
> in
> R/3 system' is checked for all printers.
>
> When I print to a locked printer, the spool request is created and output
> is
> sent to the remote writer...the printer isn't really locked!
>
> So, to help remedy this, I had to enter spad and unlock, save, lock, and
> save again all printers. This is so ridiculous it leads me to ask the
> following: is there an automated method to lock/unlock printers massively
>
> in the system?
>
> Also, it appears that by checking the box to lock a printer, several
> tables
> (or flags) are being updated in R/3. However, when starting SPAD, only
> TSP03D-PADISABLED is being checked to determine which printers are locked.
>
> First, this seems strange and can obviously lead to many inconsistencies.
> Second, does anyone know ALL the tables that need to be updated (via SQL,
> etc.) to lock/unlock printers?
>
> As always, any help is greatly appreciated.
>
> Regards,
> Mike D. Martin
> SAP Basis Administrator
> SOLA Optical, USA
> 707-763-9911 x6106
> mmartinZs...
>
>
>
> [Non-text portions of this message have been removed]
>
>
> ------------------------ consolut Sponsor ---------------------~-~>
> eGroups is now consolut
> Click here for more details
> <http://click.egroups.com/1/11231/1/_/_/_/981160717/>
> ---------------------------------------------------------------------_->
>
> To unsubscribe from this group, send an email to:
> SAP on System i-unsubscribeZegroups.com
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
[Non-text portions of this message have been removed]
Durban Tours - Südafrika Safari
BAL Application Log Documentation rdisp/max_wprun_time - Maximum work process run time
This documentation is copyright by SAP AG.
Length: 12920 Date: 20240418 Time: 115612 sap01-206 ( 3 ms )
